on Laravel 4.2 and using Sentry 2.1, it looks like there is no way to have Sentry use the same cookie as the laravel session. Right now, the cookies for Sentry are being set for 5 years into the future by default. I don't see a way in their configs for this to change. Looking in the package code, I do see the 'forever' function, but the time is not configurable from what I can tell.
The question here is how can you maintain a user's laravel session cookie is expiring sooner than the Sentry cookie, since some features are toggled on/off in session within Laravel, and if the cookie expiration is long than the Laravel session, it will throw the system into thinking it's OK for that user to be logged in when really the Laravel session is now an entirely new session.
Related
I have 3 apps and those 2 are laravel apps and 1 is vuejs
I've tried setting up session to store session data in to the database so that I can have a shared sessions between my apps.
Things work between laravel apps, however, I have trouble when it comes to my vuejs app.
Btw, in order to proceed to any of my vue routes, I have to check first if token exists and is correct.
But since I am using laravel sessions now, I guess I need to check for cookie session id now?
and if so, where do I set the cookie session id?
Better use Laravel passport (OAuth) as a token generation for you Vue application.
I have Laravel Passport implemented in my project and it is everything working well except the cookie expiration time where the tokens are being stored (that is just 1 hour).
My project consists in a backend Laravel 5.8 api (with Laravel Passport) that serves a front SPA app (Vue).
Users from my app can login successfully using a page with a Vue component that makes a POST request with the user credentials and, if the login is successfully done, users are redirected to a new URL (app home) - this redirection is a GET request that creates the "laravel_token" cookie - created by the CreateFreshApiToken middleware.
From now on, users can go everywhere inside the app and all data needed from the app components' is obtained through ajax calls (Laravel will note the presence of the cookie "laravel_token" in these ajax calls and will identify the logged in user using the JWT present in that cookie).
My problem is:
The "laravel_token" cookie that was created when user logged in was created with a lifetime of just 1 hour. Because this is a SPA, this cookie never gets updated (exchanged by a new one, with a new hour lifetime)... so, after 1 hour, when a new ajax request needs to be done to the backend Laravel server, it will receive an Unauthenticated response - that makes sense because "laravel_token" cookie is outdated.
How do you deal with this problem?
I know that i can refresh this cookie by perfoming a full refresh/reload of the page before this cookie expire but this is not a good solution in terms of user experience.
I can't make an ajax call to refresh this cookie because this is a SPA and i don't have the client_id and it's secret from client side... and also because not only this cookie is httponly but also it is encrypted by Laravel - so, i can't exchange it by a new one using JS.
Is the only solution increase the lifetime of this cookie (from 1 hour to.... 1 year, for example)? Do you see any problem with this? And where can i set this cookie expiration time? Does i need to extend the ApiTokenCookieFactory class?
I would like user to be logged in until he deliberately performs a logout request or the access_token expires (that, in my case that i am using Laravel Passport defaults, is a long-lived token of 1 year).
I would appreciate if someone could help me with this problem.
If you see something that i am not doing the correct way, i also would appreciate your comments with suggestions.
Thank you very much!
According to ApiTokenCookieFactory an expiration time of laravel_token cookie is getting from session lifetime value.
Well, just change value of SESSION_LIFETIME in .env
I use Laravel Framwork for all my php projects, and I am wondering if Laravel 5* store user critical information in session or cookies. I mean in server side or client side.
I have a Laravel 4.2 web app running under a reverse proxy. I observe that Session Id (Session::getId()) changes randomly when user login to the system, but the PHPSESSID didn't change.
I wonder why somehow Laravel Session Id is affected by the proxy but PHPSESSID does not (because everything runs very well without the proxy set up). I digged into the framework but I didn't figure out the root cause yet. How can Illuminate\Session\Store manage to get the Session ID?
CodeIgniter 2 regenerates the session id on every http-call. This leads to problems with concurrent ajax calls. This makes it possible that client and server get out of sync and the session is lost. A Fix to this is not updating the session on ajax-calls (see Codeigniter session bugging out with ajax calls). But if you use CodeIgniter as an API for a single page application, where every call is ajax, this just leads to the session never being updated at all. The user just get logged out after the session timeout (default 5 minutes).
In CodeIgniter 3 they attempted to fix this by using a write lock (see https://github.com/bcit-ci/CodeIgniter/issues/3073) on session storage. Because this relies on a Database-Feature it is only possible to safely store session information in MySQL and PostgreSQL. Redis for example can not be used (see http://www.codeigniter.com/userguide3/installation/upgrade_300.html#step-6-update-your-session-library-usage).
Finally my question is: How does Laravel handle this Problem? Laravel can use Redis for session storage. So when does laravel regenerate the session id? And if Laravel doesnt regenerate it automatically on every http request, how can this be judged in context of security aspects?
Like pstephan1187 noted, "Laravel only regenerates the session ID when you sign in and sign out". CSRF Protection is used against cross-site request forgeries, and it consists of a field that is required by default (Laravel 5) in POST, PUT and DELETE requests.
Handling this in ajax-calls is outside the functionality offered by Laravel, but can be worked around pretty easily.
For more information about Laravel sessions, see the official documentation (Which, by the way, is a very nice and easy-to-understand read).