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.
Related
I'm adding oauth support (via omniauth) to a legacy Rails app. One complication to this app is that it uses subdomain-based multitenancy (for example account1.example.com, account2.example.com) and when registering our app with oauth providers, we need to specify full URLs for our callback — no wildcard domains allowed.
No problem, I'll just reserve oauth.example.com and register that.
The problem, though, is that our session ID cookies are set for account1.example.com and such. This makes CSRF protection break and also makes passing along the client's destination a lot tricker.
I can reconfigure our Rails app to set the session ID cookie on .example.com which fixes the CSRF issue. But! If I change that in production, it will invalidate every session for every user of our app. Not a showstopper, I guess, but pretty unfriendly.
So! As the only place I want to share cross-domain sessions is for our oauth actions — is there a way I can override the session handler on a per-controller basis?
Or would I maybe be looking to write a custom Rack middleware to override session handling for some requests…?
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
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.
Is devise vulnerable to session hijacking over a normal http:// connection? I am having trouble figuring it out from the documentation.
Yes. Rails' default way to manage sessions is susceptible to hijacking.
This is because it transmits to the client all the information the client further requires to identify itself in HTTP cookies. For the most part, anybody who can intercept the HTTP connection can assume the identity of the client from Rails' perspective.
The simplest countermeasure is to only serve your site via HTTPS and have Rails issue secure cookies, which tells the browser only to send that cookie via HTTPS. The security guide has more helpful tips.
As mentioned in this email on Devise discussion group, security setup for the application is in the domain of the main application (in this case, Rails, I assume).
Do check out the RailsCast episode - Dangers of Session Hijacking to deal with session hijacking at the Rails Application level.
Rails Security Guide's section on Session Hijacking is another must read resource.
Devise provides for forcing SSL only cookies by setting :secure => true in the config/initializers/devise.rb file of a Rails App.
is it true that Rails depend on cookies? It seems that flash is a part
of session, and session uses cookies... so when i disable cookie in
Firefox, a Rails app that was working shows
[error]
ActionController::InvalidAuthenticityToken
so is it true that for a RoR app to work, cookies are mandatory?
Update: or, to make the Rails app work again, what is the simplest way? (and if it is one server only (Apache running mod_rails), then is it easier?)
They are not mandatory, but there are some things you can't do without cookies. You can turn the authenticity tokens off as described here.
It's not mandatory to use cookies, but it is the rails default from 2.x up. Using cookies serves as a simple solution to some more difficult problems that arise when you try to store cookies in memory on multiple servers (and you get into things like sticky sessions, losing user data etc).
You can set where rails stores your session data; that is the flash and anything that's associated with the specific user. In environment.rb you can configure where you store your sessions using the config.action_controller.session_store. The options for this are: :cookie_store, :active_record_store, :p_store, :drb_store, :mem_cache_store, or :memory_store.
cookie_store is the default, if you comment the option out or remove it from environemnt.rb. It's also the most versatile. If you have multiple servers, one request for a user might come into one server, and the next request might come into a different server. In this situation, you couldn't use memory_store, as the 2nd server wouldn't know anything about the current user.
By storing session information in an encrypted cookie, there is less load on the server to store this information. The only downside is that each request to the server needs to pass the cookie (usually <1k), but it's not a noticeable difference in anything I've ever experienced.
:cookie_store, :mem_cache_store and :active_record_store are the most commonly used ones.