Login Success & the Session

Hey Patrick

I'm not sure I understood your question correctly but if what you are looking for is a way to dump the documentation of your API, here you can see some examples of how to do it via a command https://api-platform.com/do...

I hope it helps. Cheers!

Hey Pax Bryan

So if you work with modals, you should send your form via ajax, and you can do everything you want in JavaScript. All you need is configure correct response on success login, for example 200 json response with some data to validate. Then you will be able to use document.location.href = document.location.href this will reload page, or document.location.href = response.redirectUrl if you pass redirect in your response, or you can just close your modal and update only needed parts of your page via ajax, you will be authenticated =)

Cheers!

Thanks for the answer ! I did a fade out and hide on success finally.
Thanks again !

Hey Xav,

I don't see authenticateUserAndHandleSuccess() has any optional arguments, so I suppose there's no default values for it, you always should pass those values. And we're passing our form authenticator here: https://symfonycasts.com/sc...

I hope this helps!

Cheers!

Hi! Thank you for your answer but I still don't understand. We've created in chapter 3 the login process just by adding "json_login" in the firewall, and it works with no extra file, listener or LoginFormAuthenticator? So I don't get what triggers onAuthenticationSuccess I want to use for the auto-login process after registration. This is probably a vey dumb question and I must have missed something obvious. Sorry.

Hey Xav,

If you have a custom Guard authenticator - I'm afraid it will handle your login requests then, and so you will be end in onAuthenticationSuccess() or onAuthenticationFailure(). I think you can easily debug it there. So, the idea would be to check if you have an AJAX request there in your guard authenticator.. and if so - handle it as AJAX request and return a json response for example, otherwise handle it as a normal post request with redirecting to the specific page.

Cheers!

Hey Sebastian K.!

Hmmm. It looks like your session is being invalidated/expired on the server side. Assuming this happens randomly (I mean, it's not a specific page that causes this), then I think it would be garbage collection on your session storage.

Check out this: https://symfony.com/doc/current/components/http_foundation/session_configuration.html#configuring-garbage-collection'

Specifically, check the session.gc_maxlifetime setting in php.ini. Session garbage control is weird... this defines how long a session needs to be idle before it is eligible to be "garbage controlled". Then there is a different equation to figure out if a specific request will actually trigger a garbage collection process or not.

Anyways, set session.gc_maxlifetime to a higher value and see if it helps. We set this to a higher value than the default here on SymfonyCasts.

Cheers!

Hey, thanks for the reply. I changed my session config to

    session:
        handler_id: 'session.handler.native_file'
        save_path: '%kernel.project_dir%/var/sessions/%kernel.environment%'
        cookie_secure: auto
        cookie_samesite: lax
        cookie_lifetime: 31536000
        gc_maxlifetime: 31536000

and it works. But I am not sure if it's the right way to set it to the same value as the cookie_lifetime?!

Hey Sebastian K. !

Excellent! So, let me clarify what each of those settings does:

• gc_maxlifetime defines how long a session can be IDLE before it is removed from the server. So, if a session has not been used for 31536000 seconds, it is eligible to be removed. But, if the session remains active, it won't be idle and will not be removed.

• cookie_lifetime defines how long the session cookie can be used. This means that after 31536000 seconds, the cookie well become invalid and the session will end, no matter what - even if the user is still actively browsing your site.

I hope this helps!

Cheers!

Hey Mohammed

You need to check your what's doing the server when you make that request. Do you have a redirect set up any where? It could come from the web server itself, or maybe a .htaccess rule. Or, it could be Symfony telling you that you need to login first before accessing such page
To where it redirects you?

Cheers!

Yes! Thank you!
It was a guard authenticator that I created before and forgot to remove it in the security.yaml file.

Hey @Алексей Хромец!

> You said that you will explain this later, but I can't see this anywhere

Yea, sorry about that! This really became a "we'll talk about this in a future tutorial" but that tutorial hasn't happened yet :p.

> What about mobile app, for example, or other resource on the other domain? For example, the api will be located on api.example.com and the client on example.com.

So, there are a few different situations. And this stuff is *tricky*, at least if you truly want to be secure. I will also admit that I'm not an expert here - though I have done quite extensive research.

A) Let's start with a mobile app. This is one of my favorite resources: https://www.ory.sh/oauth2-f.... As you can see, they highlight some problematic approaches if you're worried about "spoofing" apps that pretend to be legitimate. One caveat with that blog post is that it talks about OAuth, which *technically* isn't necessary if you only need to support authentication for YOUR app, and not allow 3rd party apps to authenticate (that's the true power of OAuth). So I believe (but have not ever done this myself) that you could also use an HTTP Only cookie for authentication with your app. For example, on authentication, you might create a JWT (or type of "token") and set it on an HTTP Only cookie. Then your mobile app would send that cookie back to the site for authentication (you would have an authenticator that reads the cookie and logs in). But overall, I know the least about mobile apps.

B) The second situation is "or other resource on the other domain". Let's assume that you are talking to an *entirely* different domain. This is tricky. The best practice (I believe) would be for your API to send back a token (JWT, or whatever, that's not as important) on a header so that your JavaScript can read it (you'll of course also need to make sure your API allows cross-site scripting via CORS). But then, you're not supposed to "store" this token anywhere in JavaScript - https://auth0.com/docs/toke... - that's really not considered secure. If you follow that rule, then you have the problem that each time the user closes their browser (or even refreshes the page), you lose the token and are no longer authenticated. From my research, in general, making authenticated AJAX requests from JavaScript to an external domain is something you should try to avoid. The safer practice is to make an AJAX request to your *own* domain, and then *it* makes the API request to the external API for you (and then returns the results). In that setup, because you have a "backend", you can safely store tokens or use cookies.

C) The last situation is "the api will be located on api.example.com and the client on example.com". Unless I'm mistaken, this doesn't pose a problem - these are on the SameSite because they share the same root domain. So you can use a SameSite HttpOnly Session cookie.

Let me know if this helps!

Cheers!

The *B)* case is smart enough :)
Thank you, Ryan!

Hey TomaszGasior

Thanks for the feedback, I think Ryan wanted to talk about the security:encode command :)

experiencing the same

I have a similar error 401, but for example if I explicitly set the algorithm: bcrypt option in security.yaml, all is working nice.

Hey Serhii

Looks like your cli and http php version configured differently or even php versions are different, checkout your php -v or php -i in console and <?php phpinfo(); ?> in browser. I guess you will find some different versions or configuration

Cheers!

Hey sadikoff Yes, you are right. I didn't notice distinguish between cli php version and symfony server php version. Thank you.

Hey!

Hmm, invalid passwords like this are hard to debug... because you can't *actually* see for yourself if the passwords are the same or not. The easiest way to try to debug this might be to switch ahead to chapters 19 & 20 - https://symfonycasts.com/sc... - to where we start encoding the plain-text password automatically. That's the only way to rule out some sort of human error, or database field being too short or any other reason that the passwords might accidentally not be matching.

I hope this helps! Let me know what you find out.

Cheers!