I'm using FOS UserBundle and I have defined a custom AuthenticationSuccessHandler to show a different home page depending on the roles, but I think it should be called only if the user originally requested the login page, shouldn't it ?
On login success I'd like to be redirected to the original request.
As described in the docs, it seems to be the default behavior, but in my case, it still uses my authentication handler.
Can someone help me to redirect the user to his original request ?
For the record, here is how I registered my authentication success handler service:
services:
security.success_handler:
class: Glide\SecurityBundle\[...]\AuthenticationSuccessHandler
public: false
arguments: ['#router', '#security.context']
Yes, the default behavior is to redirect the user to the page they originally requested. However, since you are overriding the default authentication handler, you need to handle redirecting them to that page yourself.
I recommend you look at symfonys authentication handler and mimic its process for figuring out the users original request.
Related
I use mod_auth_openidc to implement login on my website. I use multiple providers, so to initiate a login into one I redirect to:
/protected/redirect_uri/?target_link_uri=<urlencoded protected location>&iss=<urlencoded issuer>
which works as expected.
Now I want to initiate a logout in a similar manner, by refering the logout button to:
/protected/redirect_uri?logout=<urlencoded logoutpage>&iss=<urlencoded issuer>
but I simply get a 404. Of course /protected/redirect_uri does not actually exist but for some reson openidc does not handle the logout request.
The logout page is not protected and the provider has an end_session_endpoint in it's metadata.
the slash at the end of the redirect URI matters, if it is not there the request will not be considered as matching
I have implemented a login form manually in Twig and I am using the default authentication provided by Symfony 3.4 (based on username and password). Users are stored in a database, therefore I have an Entity which extends AdvancedUserInterface. I am using neither FOSUserBundle nor form builder. Just a simple form. It actually works.
The problem is that I want to integrate Google reCAPTCHA in the login process. I know how to check if the captcha is valid and implemented a custom AuthenticationListener (let's call it MyAuthenticationListener).
I know that Symfony uses UsernamePasswordFormAuthenticationListener as its default listener. The problem is that I could not find a way to change the used listener to that I have implemented.
It seems that in Symfony2 it was as easy as adding the following line in the config.yml:
parameters:
security.authentication.listener.form.class:
MyBundle\EventListener\MyAuthenticationListener
However, I cannot find a way for Symfony3. Any suggestions?
I also tried to find a specific bundle for Symfony3, but I actually could not find anything that is correctly integrated with Symfony Security, allowing me to use the recaptcha in a login form.
Thank you
Your question may be answered here:
https://stackoverflow.com/a/50800993/7408561
The solution is based on a custom-listener triggered by SecurityEvents::INTERACTIVE_LOGIN. That event is fired after verification of credentials but before redirecting to default_target_path defined in security.yml. At this position you can verify the request parameter g-recaptcha-response by calling the google recaptcha api with the corresponding secret.
If the verification fails you can throw an exception and you will be redirected to the login page.
I've overridden AuthenticationSuccessHandler but I'd like to keep the referer redirection behavior on success.
I saw that the default handler uses $request->headers->get('Referer'), I tried to do the same on my custom handler:
if (($targetUrl = $request->headers->get('Referer'))
&& $targetUrl !== $this->options['login_path']) {
die($targetUrl);
Returns me the login path:
http://my_host/login
instead of the original request. I think that it's because the firewall has previously redirected the user to the login page.
The default handler redirects me fine, so I'm wondering why mine does not.
How can I get the original request from my custom AuthenticationSuccessHandler
You should look here. determineTargetUrl is what you're asking for.
Added: It saves return path in session and then restores it (line 98). If there is no return path in user's session, handler takes Referer.
I've set basic spring authentication. When user comes to page and enters secured URL, login form is rendered, but I want to show error 403 page (or any other page i choose).
If I understand correctly I can't use access-denied-handler because user is not authenticated at all.
How do I show any other page than login form page to non-authenticated user, when he accesses secured URL?
When you are using form-login the default AuthenticationEntryPoint redirects to the login page.
You can override this by injecting a custom entry point using the entry-point-ref attribute.
You can use the code for Http403ForbiddenEntryPoint as a guideline (or use that directly if all you want is a response code sent to the client).
Add the below tag in your security context file.
access-denied-page="<name of the page>"
add this in http tag like below:
<http auto-config="true" access-denied-page="/authenticationfailed.jsp">
I have a Backbone app where we know start to implement the login. Till now I we had no login and the app starts with creating all relevant models and collection on start. Now the API demands a session cookie to response.
What would be the better solution:
having a login.html that forward to the app.html after a successful login
having the login to be part of the Backbone app with an own route
In both solution, how can I prevent that the user sees the login dialog again, just by pressing the back button?
I use the standard way of login handling, a simple login page separated from the application.
/admin/ in this route I have a simple middleware checking for the user session if the user is not authenticated, he is redirected over /admin/login.
Once the user obtains a valid session he can freely go to /admin/ where my application resides. The same apply when you need to authenticate users with some OpenID or OAuth provider.
There is no use in handling authentication in the browser since it's too much simple to handle it in your backend. In fact in my backend I have only three standard routes:
/* accessible routes */
/admin/login
/* protected routes: */
/admin/
/admin/(...)
/admin/logout
For the back button issue, you just need to know if the user already have a valid session token, then redirect/trigger to the right route (beware of redirection loops)