Target Path: Redirecting an Anonymous User

How can I specify the target path via a hidden input in my form? Every page has the login form embedded in it on my site, so there isn't the initial redirect to the Login page to set the target path. Once logged in I want to redirect back to the page the user was on.

I've tried
<input type="hidden" name="_target_path" value="{{ path('current_page') }}"/>
but that doesn't work with Guard (I understand it's part of another login system in Symfony called `form_login` ¯\_(ツ)_/¯

Hey Peter,

Yeah, probably it won't work out of the box, though you can read the "_target_path" using Request object in your Guard authenticator and do a proper redirect :)

Cheers!

Use the following code if you care about readability:

    public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey)
    {
        $targetPath = $this->getTargetPath($request->getSession(), $providerKey) ?:
            $this->router->generate("app_homepage");

        return new RedirectResponse($targetPath);
    }

Hi there,

I don't know why but my app doesn't work properly.

Firstly, I don't follow your paths. My ones are:
path: "/" , undefined (no pages pointed);
path: "/login" shows the login form;
"/admin" enters in the admin zone (obvious).

I added an user into my database ("admin", role ["ADMIN"]...)

In prod environment:
when an anonymous user attempts enter into the "/admin" sees the "403" error page (I have a customized page) but my app doesn't redirect them to login page. -> is it correct? when I login as admin, my app shows the 403 page. why?

This said, my access_control should be:

access_control:
        - { path: ^/admin, roles: ADMIN } // the same role for the admin user in database;

and my onAuthenticationSucess method contains the following code:

 public function onAuthenticationSuccess(Request $request, TokenInterface $token, string $providerKey)
    {
        if ($targetPath = $this->getTargetPath($request->getSession(), $providerKey)) {
            return new RedirectResponse($this->router->generate('app_login'));
        }
        return new RedirectResponse($this->router->generate('app_admin'));
    }

To my mind, this logic is right for me....but in prod when I enter as "admin" it fails.

What should be the value of "target_path" for me? What is its role? What am I missing?

Best regards.

Hi again @AbelardoLG!

Hmm. So yes, your app is behaving oddly.

> when an anonymous user attempts enter into the "/admin" sees the "403" error page (I have a customized page) but my app doesn't redirect them to login page. -> is it correct?

This is not the correct behavior. Because your user is anonymous, it should trigger something called an "entry point", which usually is something that redirects to your login page. Can you paste your firewalls config? The entry point is usually something that is configured automatically for you based on your "authentication mechanisms" under your firewall.

> when I login as admin, my app shows the 403 page. why?

I think I know the problem here. There is a rule with roles: they must start with ROLE_. So, when you set the role on your User, use ROLE_ADMIN instead of ADMIN. Then protect it in the access control with ROLE_ADMIN. Here is some background about why this is a requirement, if you're curious: https://symfonycasts.com/sc...

> and my onAuthenticationSucess method contains the following code

Your onAuthentiationSuccess is definitely not the problem in this situation - so you can rest easy about that :).

Cheers!

Hi there!
First of all, thanks for replying to my question.

Secondly, here is my security.yaml file:

security:
    encoders:
        App\Entity\User:
            algorithm: auto
    # https://symfony.com/doc/current/security.html#where-do-users-come-from-user-providers
    providers:
        # used to reload user from session & other features (e.g. switch_user)
        app_user_provider:
            entity:
                class: App\Entity\User
                property: username
    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false
        main:
            anonymous: lazy
            provider: app_user_provider
            http_basic:
                realm: Secured Area
            guard:
                authenticators:
                    - App\Security\LoginFormAuthenticator
            logout:
                path: app_logout
            # activate different ways to authenticate
            # https://symfony.com/doc/current/security.html#firewalls-authentication

            # https://symfony.com/doc/current/security/impersonating_user.html
            # switch_user: true

    # Easy way to control access for large sections of your site
    # Note: Only the *first* access control that matches will be used
    access_control:
        - { path: ^/admin, roles: ROLE_USER }
        - { path: ^/page/1, roles: [ADMIN, PAGE_1] }
        # - { path: ^/profile, roles: ROLE_USER }

Thanks for helping me! :) Brs.

Hey @AbelardoLG!

Ok, so you have 2 authentication mechanisms: http_basic and your LoginFormAuthenticator. Each of these has an entry point inside of them - entry point is logic that says "what should we do if an anonymous user tries to access a protected page?". When you have multiple authentication mechanisms, Symfony will choose one of them, unless you explicitly tell it which one to use. I believe it's choosing your LoginFormAuthenticator.

So, a few questions:

1) What behavior *do* you want when an anonymous user tries to access a protected page? Probably redirect to the login page?

2) Does your LoginFormAuthenticator have a start() method? That is the method that's called when an anonymous user tries to access a protected page (that function is your entry point). If you're extending AbstractLoginFormAuthenticator, then it's implemented for you - https://github.com/symfony/... - which would not explain why nothing is happening in your case.

Anyways, let me know - we're close to figuring out what's wrong :).

Cheers!

Hi there!
1) Yes: a user without any session goes to /page/1 or /page/2 -> the system redirects the user to a login page with a 302 HTTP response code
2) No, I haven't overriden that method. Yes, my LoginFormAuthenticator implements AbstractFormLoginAuthenticator
Cheers!

Hey @AbelardoLG!

Ok then! So, the "start" method in AbstractFormLoginAuthenticator should already be called whenever an anonymous user accesses a protected page. Based on what you're telling me, that may or may not actually be happening. So, let's do some debugging!

1) When an anonymous user tries to access a protected page, what is the error you see exactly? You said it's a 403, but what is the exact error message from Symfony? A screenshot would be best ;).

2) Try opening the core AbstractFormLoginAuthenticator. Inside the start() method (on the VERY first line), add a die('here'). Now, when an anonymous user tries to access a protected page, do you see this "here"? Or do you still see the 403 page?

Cheers!

Hi there,
Finally, I opted by the http basic authentication due to a constraint in my requirements; therefore, the AbstractFormLoginAuthenticator (and the related code) were removed from my code.

My app works fine :)

Thanks for your time&help for solving my issue. :)

Warmest regards, weaverryan

In this video we made sure that the user is redirected after the login to the same page that he tried to access without being logged in.
How can I exclude routes from this? I ran into an issue where my users get redirected to a page after login which I don't want. For example an api route which was called from the frontend and returns json.

Don't get me wrong here I want to keep this functionality in general I just want exclude some routes so that the user is never redirected to them right after logging in.

This is the code I'm talking about : (class LoginFormAuthenticator)

    public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey)
    {
        if($targetPath = $this->getTargetPath($request->getSession(), $providerKey)) {
            return new RedirectResponse($targetPath);
        }

        return new RedirectResponse($this->router->generate('app_homepage'));
    }

Hey Ecludio,

I see. Well, it's possible, while you're in PHP code - you can do whatever you want before returning the response. It means, that you can check if the targetPath does not match some undesirable routes, and if it's not - redirect to the targetPath. But if it does match - redirect to homepage for example :) I suppose you can use "strpos()" for this kind of check, or more complex "preg_match()" for some regular expressions. Unfortunately, there's is no such functionality out of the box.

I hope this helps!

Cheers!

Thank you very mutch. It worked wonderful!

Hey Ecludio,

Perfect! Thanks for confirming it works for you :)

Cheers!

Hello symphony cast !
What if i want to catch the target from a direct href pointing on 'app_login' ? Is it not risky to store _security.main.target_path from controller ? What if someone spam the request ?

Hey Virgile,

How exactly? Could you give a little example? I don't see we save "_security.main.target_path" from controller in this chapter...

Cheers!

Hey Victor,

I used it because i did want to save the target path even if the user came directly from href="app_login". So i wonder, if there is a risk if i save the target path each time someone is reaching the page where i use it (_security.main.target_path).
I wonder, what if someone discover this feature of my app, is there a risk that this person could "overflow the session" by spaming the url ?

Hey Virgile,

Well, if you afraid of overflowing your session - you might want to add an extra check before setting that target path. And if something is weird and you think it's spam - set it to default URL for example. But even without any checks it should not make any harm I think, at least if you do not do any update/delete actions on your website via GET method, i.e. use POST or DELETE for it. GET methods should not be harmful at all, because they are just for getting information, not modifying or deleting it.

Cheers!

Awesome thanks for your clear answer <3

i'm getting "Unable to generate a URL for the named route "routename" as such route does not exist".
Anyone got this one ? It has something to do with annotations because i was able to find the route that i declared manually in routes.yaml.

I don't why it didn't work before but it works now :|

Hey Wuwu,

It might be due to cache, so it's always good to try to clear the cache first. If the problem still exist - then dig more deep :) Glad to hear it works for you now

P.S. you can use "bin/console debug:router" for debugging the route names and URLs in your application - it's pretty useful.

Cheers

Hi!
I give all users during registration process "ROLE_UNACTIVATED".
How is it possible to redirect all users with ROLE_UNACTIVATED from any site page to an activation page?
Thanks a lot!

Hey Viktor Z.

You can add a subscriber php bin/console make:subscriber and listen to the kernel.request event. Such subscriber would check for logged in user roles and if it has that role, then you can redirect him to wherever you need to

Cheers!

Hey guys,

Redirecting after login works if the target path is listed the access_control part of my security.yaml. However, if I have a controller with the following code,

        
       $user = $this->getUser();
        if (null === $user) {
            return new RedirectResponse($this->container->get('router')->generate('app_login'));
        }

The target path is null in my LoginFormAuthenticator.

How do I set the target path before returning the redirect response?

Thanks!

Hey Dan_M

You need to set the new route into the user session by doing something like this:

$request->getSession()->set('_security.main.target_path', $returnPath);

Cheers!

This content is the same as previous chapter

Already fixed then ^^

Hey guys,

Thanks for mention it. Yeah, this is just a draft yet and looks like it was fixed already :)

Cheers!