I have an application built on Rails 2. If the user opens two instances of the same application(dev, uat or any two), it logs out while the person is active. Also this behavior is inconsistent. sometimes it happens within 2 minutes of login and sometimes it happens once in half an hour.
Also a very interesting thing to notice is If I disable the validation for CSRF token, the user never gets logged out unless the session times out or the user logs out voluntarily.
--Update--
After digging more into the issue I found out that the CSRF is not the cause of this issue. The session id is getting deleted from the cookie. What could be the possible cause of the issue
So As I already told in my question that the CSRF validation is not the cause of the log out issue. So I digged deeper and saw that randomly the session_id cookie was getting deleted and that is when I try to use the application further it was obviously getting logged out.
So the fix for this was to make sure that the session_id cookie should not be allowed to be deleted. In order to do so I marked the cookie as secure. Although I was still not able to find out the root cause of this cookie deletion.
I was using the SqlSessionStore to store session info. Following is the Fix that I put:
ActionController::Dispatcher.middleware.swap(:"ActiveRecord::SessionStore",
SqlSessionStore, {:secure => true})
Related
I recently had to set SESSION_DOMAIN=".example.com" to be able to access the laravel session cookie from a subdomain sub.example.com.
After this, part of the previously logged users started reporting Error: Request failed with status code 419 on post request (reportedly even after logging in again), others report being unable to log in at all.
I am unable to reproduce this problem. No related exception or errors are logged, however this clearly suggests that it's an issue related to the session and/or XSRF-TOKEN cookies.
How to fix this?
Will flushing all my redis session data, force all users to log out or remove all cookies fix this or make it worse?
Changing the SESSION_DOMAIN caused the coexistence of two cookies named session in the browser with different domain configurations.
Setting the SESSION_COOKIE to a new value and flushing the remember_token solves the problem.
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 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.
After loggin in OneDrive through a web application as explained here (http://msdn.microsoft.com/en-us/library/dn659751.aspx), I can see that a session (WL.getSession()) is obtained correctly. However, if I make a refresh on the page, it is getting lost. I guess this is due to some cookies management. Is it possible to have the session not cleared at refresh?
Thanks,
Stanislav
Typically, you should call WL.login or otherwise check login status first (see WL.getloginStatus). These will return a session object if the user is logged in and has consented, so on refresh your session object should not be null unless they have logged out and you need to sign them in again. You may be "losing" the session depending on when you are calling WL.getSession()
Check out the interactive SDK sample on signing users in
I am new to lift and trying to write a simple login application. When I leave my login page for some time, and I enter username and password it doesn't login instead it perform session expire behavior.
I checked the log and found that whenever I got INFO - Session navoo0xdu1ia1vi8m1c0cnl3w expired log message, the above behavior happens.
I am not able to understand why request is using the existing session, even if it's already expired. Please guide me where can I found documentation/example/tutorial to understand this behavior and how to implement simple session based login functionality.
Any help will be appreciated since this problem is bottleneck to me. I googled a lot but couldn't find anything useful.
If your session is expiring then it is because of one of two things:
1) The value set in LiftRules.sessionInactivityTimeout
or
2) The value set for session expiry within your container session.
The former is actually set to nothing by default, which means the latter will override it. Be aware however that provided you are interacting with Lift and have not disabled the heartbeat pulse then sessions do not expire. If you watch the AJAX traffic you will notice a page heartbeat used for function GC which keeps the page bound functions alive.