It is possible to expire cookies automatically when the user logouts? Or it should be done manually? If manually, how can I get a list of all cookies I have during a session? (I know the names of all my cookies but I do not want to explicitly set every cookie to nil manually)
Shortly - no. Rails its a pretty web framework. You needn't worry anything, only for business logic.
Read off docs about security for more details.
Related
I have a Rails app with Devise and was checking on front end if my Rails app was implementing cookies in order to comply with European rules regarding cookies.
I was a bit surprised as my Rails app actually add cookies to the client even without any Devise authentication ...
The cookie has name _myapp_session
Actually it is a good thing as I could add the cookie law information inside this cookie (user gets to see the cookie law warning only once)
...Yet each time I reload the root page in my browser the cookie is renewed.. So it doesn't actually look like a session cookie.
Is there a wrong setup in my initializer or can someone help me fix this ? (or maybe this is completely normal)
EDIT : Maybe my mistake : the cookie value is changing on every page yet the session creation time is not changing so I guess it is still valid to consider it a session cookie. I will search the web for a thorough explanation on cookies as the cookie value changing all the time is probably a feature.
Cookies are created by default in Rails Application.
Also, you're probably using Rememberable module in Devise which uses cookies.
Devise 'refreshes' csrf token after each request. Hence why it changes.
Did you try to look inside cookie and see what it contains?
Here's how you might do it (old rails version):
https://blog.bigbinary.com/2013/03/19/cookies-on-rails.html
Spring Session uses a different format for its session cookies than Tomcat does. So if you implement Spring Session, even if you would name the session cookie JSESSIONID, all the users have to login again.
This is a point where you potentially lose users, because nobody likes to login. Perhaps this is an edge case, and certainly it's not worth a huge amount of trouble, but I'm curious if it's possible for existing users to use their already stored Tomcat session cookies?
You can implement your own org.springframework.session.web.http.CookieSerializer that matches Tomcat's default cookie serialization and register it as a bean.
Spring Session configuration will then pick it up and use it - see org.springframework.session.config.annotation.web.http.SpringHttpSessionConfiguration#setCookieSerializer for more details.
Can we restrict from storing cookies in sharedHTTPCookieStorage by default?
I am using other approach for session authentication and don't want cookies to be sent to server on each server request. Currently I read all cookies from sharedHTTPCookieStorage and delete them manually after Login.
It would be better if they are not set automatically by default at first place.
I'm not an expert on this. But I worked on some apps that need to cache zero to none info for security reasons.
I think that you could go with a combined approach.
Defining a no-caching policy to responses, on NSCachedURLResponse and also intercepting calls with your own NSURLProtocol.
Here's some info on the whole URL Loading system on iOS
I hope it helps a little! Good luck!
Because of the awesome EU directive on allowing users opt out from having cookies stored I have the following problem.
I have a message that displays at the top of the screen that asks the user to opt in or opt out.
if the user opts in, cookies are turned on using rack.policy, and the message is hidden. A cookie variable is set to say that the message should not be shown again for future visits. Perfect
If the user opts out. Cookies are disabled, fine. the message is cleared.... and a session variable is set to say don't show the message for this session. This would be fine, but it seems the session variable is saved in the same way as a cookie and the rack policy does not allow it to be displayed. The message therefore flashes up on every single page.
So first, thank you EU. Second, how do I save a "session variable" without saving to a cookie?
Unless you try going for something more exotic like local storage offered by the browser, you can't. The rails guide explicitly states:
All session stores use a cookie to store a unique ID for each session (you must use a cookie, Rails will not allow you to pass the session ID in the URL as this is less secure).
I'm no lawyer, but for what it's worth I believe that law is intended to apply to cookies used for marketing/tracking purposes and does not apply to cookies needed for the site to function like cookies used for authentication or ephemeral storage. With this in mind, you could use the rails's session cookie for must-have data and use separate cookies for other purposes that your application can disable.
I wouldn't take it as gospel, but this Wired article seems to a good job of providing a simplified explanation.
It would be great to have a supporting doc for the same.
I'm assuming the question can be restated as "Does Devise use a cookie to keep track of your session after authentication." If so, the answer is yes.
To test this, clear your cookies, log in and then check your cookies again. You'll see one for your website named after your app.
#Rodrigo, sessions are enabled by cookies. That's how the session can follow you through multiple pages. HTTP is inherently stateless. Cookies allow you to save state.
Not directly.
Devise is built on top of Warden, which uses the session. I don't see any easy way to use cookies for authentication (although you may use rememberable to keep it recorded between sessions). Sessions are enabled by cookies, so it uses the cookies indirectly.