I have a fairly simple web app that uses cookies to store some information about the user and to authorize them on each request. When the user first logs into the site a cookie is created and some encrypted information is stored in there, the expiration is set for the current time plus 24 hrs.
What I want to achieve is that whilst a user is moving through the web app their expiration date is constantly being increased to be 24 hrs from the current time.
What is the best way to do this? Should I be using a attribute on the controller?
You could write a custom action filter that will execute before each action. This filter will read the cookie from the request and set a new cookie with the same name and value but with a new expiration date.
Related
I have an ASP.NET MVC application. I have the following:
<sessionState timeout="60" />
My question is that if a user goes on a page and takes more than 60 minutes to fill out all the fields on the page, will that constitute a timeout? What constitutes a timeout? Does a user need to go through different pages so timeout will not happen?
Simple answer is - Yes, a person taking more than the timeout (60 minutes in your example) on the same page would cause a timeout.
Session is server side, so if no requests are sent to the server for the timeout period - the session will expire and all the saved session variables will be lost.
To complicate things a little bit, if your page is making AJAX calls to the server - those could keep the session alive without navigating to a different page.
session data is stored for 60 minutes from the last request. So, if you access a page and something is stored as session data for you, it will be automatically removed after 60 minutes unless you have made a new request within this time period.
you shouldn't try to use sessions to store data for long periods of time.
I'm using Rails 4 with cookie based session store, found that Rails 4 will give me a different cookie every time I refresh the page, but it can still identify me.
Compare it to another rack app which uses Rack::Session::Cookie, it will only send Set-Cookie for the first request, until some changes to session data were made.
Why are they designed differently? Is there any reason behind?
It's because of the way Rails handles session storage and cookie encryption:
the default session store will try to write the session data to an encrypted cookie on any request that has accessed the session (either to read from it or write to it),
the encrypted value changes even when the plain text value hasn't,
the encryption happens before it reaches the code that's responsible for checking if a cookie value has changed to avoid redundant Set-Cookie headers.
I go into much more detail in answering this question: Why is rails constantly sending back a Set-Cookie header?
Rails cookie_store default use the EncryptedKeyRotatingCookieJar, and generate the encrypt_and_sign value. That value use MessageEncryptor#_encrypt method, which use the Random 【cipher.random_iv】. So, every time the same value will generate a different encrypt_and_sign result.
I need to set a cookie which expires after 4 hours. Now, the users can reside in multiple timezones. So, if I set the cookie in rails and set expiry based on server time, would it lead to invalid expiry times for some users or does rails handle this issue or does browser cookies themselves handle this issue ? Should I set this cookie in javascript, so that user's browser time is taken to set the expiry?
Thanks!
I think you want to expire cookie after 4 hours since it was set. You just need to specify time that should be ahead of 4 hours from current time. There is no concern with timezone. Because 4 hours is same for all timezones :P
cookies[:login] = { value: "XJ-122", expires: 4.hour.from_now }
Source
In my Rails application I make set of AJAX calls at once and that causes sending the same session cookie for each request.
The problem is that rails sets new session cookie in every response and therefore it expects that cookie value in the request after.
I'm looking for server-side solution because I don't want to chain those requests (they are time consuming).
Is it possible to change this behavior? And what security risks would come with it?
(I'm using Rails 4.1.0)
Many thanks
If the user doesn't already have a session cookie then there is nothing you can do.
If you can guarantee that the user already has a session (for example, if you require users to be logged in) then you may be able to do this with a server side session store.
With a server side session store the session cookie just contains an identifier - even if your overlapping ajax requests change values in the session they will not change the session cookie. In general this is better security wise: for example, old sessions can't be replayed after the user has logged out. Rails switched to the cookie store by default for performance reasons: no external data store needs to be accessed (however it does slightly increase the amount of data sent on each request)
Switching to a serverside session store isn't enough though and still leaves you open to race conditions. It is very easy to end up with a sequence along the lines of
Request A loads session
Request B loads session
Request B completes, saves session
Request A saves session and overwrites the session changes made by B
You need a session store that will attempt to merge any changes it has made with any changes that may have occurred from other requests.
I wrote such a session store some time ago. I haven't updated it for rails 4, since it isn't something i need anymore but you may be able to (or at least find inspiration in it)
In magento, the value of the cookie life time we set from the admin control panel , is browser dependent.
I set the cookie life time value for my default store configuration scope as 600 seconds.
I want to know if this value is browser dependent. Suppose I login to my store at 10 20 am in firefox and 10 25 am in internet explorer, by using the same login id. Then what will happen after 600 seconds, to both these browsers.
Sessions are in most cases tied to the useragent (browser), thus logging into the same account from two different browsers/browser sessions will create two different server-side sessions with each one having it's own expiry time. Some systems don't allow multiple sessions to be started for the same account, but in my experience this is not the case with Magento.