I need to display, for example, the "Bad credentials" message in another language.
So far I found that it is thrown as an exception in
\vendor\symfony\src\Symfony\Component\Security\Core\Authentication\Provider\UserAuthenticationProvider.php
authenticate function as
throw new BadCredentialsException('Bad credentials', 0, $notFound);
I am wondering what would be the recommended way for showing this message in another language. Just changing the string in this place seems non-optimal...
Also there are other messages that might probably be shown during authentication.
I am using the JMSSecurityExtraBundle and FOSUserBundle and I guess there could be some built in functionality to handle this...?
Override login template: copy FOSUserBundle/Resources/views/Security/login.html.twig to app/Resources/views/Security/login.html.twig (see doc, video)
Add trans filter to error variable in login.html.twig (see doc):
{{ error|trans }}
In your translate file src/YourBundlePath/Resources/translations/messages.{locale}.yml add:
Bad credentials: Your error text
Related
We're calling a REST-API technical profile in the OrchestrationStep. In the event where the REST-API returns an error, it redirects back to the application and displays the error as a query string.
(e.g.#error=server_error&error_description=AADB2C%3a+No+code+provided%3a+Conflict+error%3b+RequestId%3a+No+request+id+provided.%3b+Additional+Info%3a+No+additional+info+provided.%...)
Is there a way that instead of displaying the error in the query string, it will display a custom error page?
Also why is api.error not displayed in this case?
Note: The REST-API is needed to be called in the OrchestrationStep rather than the ValidationTechnicalProfile
Assuming you are using Oauth/OpenId, the way B2C responds to the application is based on the response_mode query parameter that's passed to it when you call the policy. The response_mode can be query, form_post, or fragment.
Here's a link to the Microsoft's auth code flow docs that shows the response_mode query parameter in action along with it's available options: https://learn.microsoft.com/en-us/azure/active-directory-b2c/authorization-code-flow#1-get-an-authorization-code
api.error only displays for unhandled exceptions and doesn't cover every use case.
An answer to another post (Error handling in Azure B2C Custom Policy REST Call) from someone on the engineering team states that anything but a 200 from an API halts the journey execution and returns an error to the app immediately, so unless you put the rest call in a validation tech profile, this is the behavior you're going to get.
Short Version
Please read at the very bottom for a short version of the question.
Situation
In a question I asked last week, I struggled in finding a solution, which makes our asp.net error visualization waterproof, since there are some edge cases where the asp.net exception handling fails and hence no proper exception visualizations can be created:
How to properly set up ASP.NET web.config to show application specific, safe and user friendly asp.net error messages in edge cases
Desired Solution
As an alternative to the way I described there, in my opinion the best way to make the exception visualization reliable, would be to use the httpErrors-element in system.webServer as a failsave so that any error which is not properly handled by asp.net, leads to a generic error page which is shown based on the settings of the httpErrors-element .
To accomplish this, there must be two things possible:
Error pages properly handled by the application must pass through iis without being replaced with a generic error message
Errors which could not be processed properly in asp.net, must be replaced through IIS.
It is my understanding, that this very behaviour is meant by the existingResponse="Auto" parameter in the httpErrors-element.
The ms documentation states:
Leaves the response untouched only if the SetStatus flag is set.
This is exactly what is necessary: Any successful error page creation in the application (through Application_Error or through an explicitly defined error handling page) can set
Response.TrySkipIisCustomErrors = true and IIS would let the error page pass through. However, every other error which was not successfully handled by the application in asp.net, would not set the flag and hence get the error page which is specified in the httpErrors-element.
The Problem
Sadly, it seems that in MVC5-applications (I don’t known whether the same behavior is true in other environments), the Response.TrySkipIisCustomErrors (fTrySkipCustomErrors) seems to be set automatically to [true], even if it is not set by the application.
Hence we are at the same place, as in my other post: If the error handling of the application blows, there is no way to show an application specific error with existingResponse="Auto", since its not possible to reset the fTrySkipCustomErrors flag.
As an alternative, one can set existingResponse="PassThrough". That's what we do currently, since we want to generate our error pages with a support-code and other helpfull information about the error to be shown to the user, or one can use existingResponse="Replace", but this is not an option, since it replaces any error page so that we don’t can show the user any error-specific information such as the support-code mentionen before.
Quesition in Short
The question is therefore, how to make sure that MVC5 (asp.net) does not set the fTrySkipCustomErrors flag automatically to [true], since there are situations, where no application code is executed and hence the Response.TrySkipIisCustomErrors (fTrySkipCustomErrors) cannot be set to false, what renders the existingResponse="Auto" parameter moot.
To check such a situation where the asp.net MVC5 exception handling blows but the fTrySkipCustomErrors flag is set to true, please request the following page from your MVC5 application:
http[s]://[yourWebsite]/com1
Please note: I'm not interested in disabling the above error. It's an example. I want the error visualization reliable and not to have to circumvent every error that possibly can blow asp.net's error handling mechanisms.
I developed a rest service by mule, and I want to validate the input params, throws exception when the params is invalid, and the error handler could catch the exception(a custom exception with error code and message included) and get the error code and message which i could return to client.
Currently I use the choice router to evaluate expression, and set the error expression. I think it's awkward， and inconvenient.
I read the document, seems there is no such example, so what's the best way to handle the situation?
If you go beyond a trivial REST resource, using choice routers won't cut it.
You have two better options:
Use JAX-RS + Jersey module: http://www.mulesoft.org/documentation/display/current/Jersey+Module+Reference
Use APIkit: http://www.mulesoft.org/documentation/display/current/APIkit
The former is based on a standard, the latter is proprietary. In the future, the latter will receive most of MuleSoft's attention.
I'm looking for a good way to handle errors in Zope's page templates. What I already know is:
<div ... tal:define=...
tal:on-error="string:Oops!">
This text will be replaced in case of errors
</div>
or
<div ... tal:define=...
tal:on-error="error/value">
This text will be replaced in case of errors
</div>
or
<div ... tal:define=...
tal:on-error="string:${error/type}: ${error/value}">
This text will be replaced in case of errors
</div>
However, it might be desirable to use a more elaborated error handling method, e.g.
to display details depending on certain permissions
to log and/or report the error to the maintainers
to have an easy way to create some pretty HTML without the need of a lot of code in the template
I had a look at the old Zope documentation page and created a script object like described there (amending the missing colon, of course); however, it won't work (I tried both on-error="here/errHandler" and on-error="here/scripts/errHandler", and I added *args and **kwargs, without success).
I tried to build a browser (on-error="here/##talerror") for such purposes, and it was used alright, but it didn't seem to get the error object.
I'm using Zope 2.10.7-final and Plone 3.3 (old, I know).
Is there a way to hand over the error object to the browser, or to make the script object work?
P.S., just to get it clear: This is not about sqeezing lots of logic in a template - no sermons about templates and logic, please! My goal is to find the error in existing templates, i.e. which part of the logic (which is implemented somewhere behind the scenes, in browsers etc.) fails in which way. The documented way of using an error script doesn't work for me (maybe I'm missing an important part?), and an error handling browser apparently doesn't have access to the error object.
I'm using webflows in Grails and I'm currently writing tests for it. Now, inside I've got something that throws an error so I set a message to the flash scope before redirecting:
...
if (some_condition) {
flash.message = "my error message"
return error()
}
...
Now, I know that when I'm going to display this in the GSP page, I access the flash message as
<g:if test="${message}">...
instead of the usual
<g:if test="${flash.message}">...
So anyway, I'm writing my test and I'm wondering how to test the content of the message? Usually, in normal actions in the controllers, I follow what's written in here . However, since this is a webflow, I can't seem to find the message even if I check controller.flash.message / controller.params.message / controller.message . I've also tried looking at the flow scope...
Any ideas on how to see the message then? Thanks a bunch!
Based on your example, you can access your flash.message as controller.request.message in your webflow test. I did a lot of googling for this same exact issue and a lot of webflow documentations talk about it merging all scopes into the "view model". But I also read somewhere that it merges the flash scope into the request scope for redirection. That's what prompted me to try looking in the controller.request in my test case.