I am working on Laravel 4 application and using Sentry for authentication. I need to add Keep Me Logged In functionality into my application. I have googled around and found that passing second variable to Sentry::login($user, $remember) sets up a cookie. I have done that and can verify that it is working from the browser (Chrome). But somehow whenever I try Sentry::check() after a day it returns null for cookies. Even when the cookie is present in the browser. Can anyone point out what am I doing wrong? Same happens when I attach my custom cookie to the response.
This scenario happens on my production server. Whereas it works fine on my local server.
PS: Lifetime of the cookie is set to forever (5 Years)
After working around for sometime on the issue I was finally able to resolve the issue by creating and attaching custom cookie to the response after login. And then wrote a middleware to check for that cookie. If present then login user and continue.
Related
I have been playing for a couple of days with a stateless Laravel API with JWT based authentication, where I store the token in a cookie.
All is well, except for the cookie (in)validation...
I set my cookie like so
Cookie::queue(Cookies::NAME, $token, (int) env('COOKIE_VALIDITY'), Cookies::PATH, env('COOKIE_DOMAIN'), env('COOKIE_SECURE'), Cookies::HTTPONLY, Cookies::RAW, Cookies::SAMESITE);
$redirectUrl = $request->query('redirectTo') ?? route('home');
return redirect($redirectUrl);
This works, it does set the cookie.
However, my cookie Expires/Max-Age seems to be one hour behind, always.
2019-10-12T08:51:35.737Z (when it is actually 9:51)
The cookies gets sent correctly on all subsequent requests though.
The biggest problem however, is cookie invalidation.
My logout action looks like this
return redirect('/login')->withCookies([Cookie::forget(Cookies::NAME)]);
The action gets called to, but the cookie remains unchanged.
I also tried with the cookie()->forget() helper, this has the same result.
Any clues to what I am doing wrong here?
Ps: I do see that laravel by default adds a session cookie as well, I suppose this is normal, due to the fact that I reach the site as an anonymous user and therefor receive a session for that?
Im asking because the challange for me is to have a full stateless API that only uses server side rendered login page and then redirects back to some kind of SPA.
All help is much appreciated.
To whom it may concern, I have found the problem.
Apparently, specifying the cookie name is not sufficient.
return redirect('/login')->withCookies([Cookie::forget(Cookies::NAME, Cookies::PATH, env('COOKIE_DOMAIN'))]);
Works perfectly.
Once my webpage is deployed in IIS it seems that i am unable to properly switch tenants until i log into the default/host first. I don't want to require my users to have to do this before being allowed to switch to the tenant. It seems like the view is not properly being updated but i'm not sure why. I am using the ASP boilerplate template as a base and have not changed any of the login code/functionality at all.
So i tracked down the issue. For some reason when it goes to set the document.cookie value that includes the path and expire along with the tenant ID for whatever reason the browser is not updating the document.cookie with the according values. The javascript itself is not failing.
The fix is to just set the tenant portion of the cookie by itself and it works. Maybe someone can explain this behavior, but i tested the string and it will update the cookie just fine if i have logged into a tenant or host first.
Just seems once the session times out or is marked as bad this issue comes up.
I'm trying to retrieve a cookie from a middleware in Laravel 5.3 but it seems like $request->cookie('language') is empty. I'm guessing that it is only set after the middleware runs.
I read somewhere that I should use \Cookie::queued('language'), but it's still empty.
Is my only option using the $_COOKIE variable?
When do you set this cookie?
Remember that cookies are stored in the browser, so the user needs to get the response in order for you to be able to retrieve the cookie later.
You should be able to get the cookie after the cookie is being set by a response that's successfully sent to the user. Remember also that if you use dd(), that doesn't let the cookie get created, because it skips all cookie headers from being sent to the user.
Another problem you might face for trying to get cookies from middleware is that it might not get decrypted automatically, so you'll have to do it yourself.
Example:
\Crypt::decrypt(Cookie::get('language'))
If someone encounters this problem in 2019 with Laravel 5.8:
You will need to use \Crypt::decryptString(Cookie::get('language')) or \Crypt::decrypt(Cookie::get('language'), false).
Otherwise it will try to unserialize the string and then strange things happen.
Our Laravel 5.1 application has been using the "native" session driver setting (configured in the .env file). With it set this way, we were able to use the laravel url.intended behavior to redirect the user to the url they were attempting to access prior to being authenticated.
We had to change it to "cookie" because every time we use Amazon's Opsworks system to deploy a new build, users were logged out because their server-side session files were no longer available. Once we changed it to cookie, the users remain logged in even when we deploy a hotfix or new build.
However, with it set to cookie, the url.intended does not work at all. I tried hacking together some solution by adding a custom url intended node, but it just won't work. It seems like when the user attempts to access a url prior to being logged in, it sets the session info, but then the application redirects the user to the login page where it's getting nulled out.
I'm using Debugbar to look at the session vars and I'm going crazy. I'm already bald so I have no more hair to pull out.
Does anyone have any ideas?
We ended up setting up a Dynamo database at first and then transitioned to Redis on a common server. We have a load balancer and don't want sessions getting lost or corrupted by switching servers so all cache is now being stored in that common location.
I'm just installed a fresh L5 app. I'm attempting to use database driven sessions however a new session appears to be created on each page load.
Has anyone come across this issue and managed to resolve?
"_token" value is new on each refresh.
I'm happy that the cookies have been configured correctly.
Not sure where to look next.
Any suggestions would be a huge help.
Thanks in advance
Have you ensured your session domain is set correctly? Your session domain should be the domain alone, for example domain.com, no URIs or protocols (http://), etc.
You may also want to check that SESSION_HTTPS is set to false, unless you're accessing your site over https.
If either are not set correctly sessions will not be correctly stored by the browser, so each request results in a new session.
The _token key will always be a new value for each request, this is part of the CSRF security feature.