We have a few web applications that share a cookie value ssoid.
When the user logs into our Rails application, we want to set the ssoid value in the cookie but Rails is URL encoding the value by default.
cookies[:ssoid] = session[:token]
Value written to the cookie store is
ABCpRyan0fLwMamiT%2F9GGk2o%2FAPckq1C8PbHCotxmgUk%3D
instead of
ABCpRyan0fLwMamiT/9GGk2o/APckq1C8PbHCotxmgUk=
Is there a way to avoid this?
I think that you can use the memcached gem to store cookies in one commun place and share that cookie across multiple apps you can also take a look at sharing session across rails apps on different subdomains as a subdomain is seen as a different site or app
I hope that I could help.
Related
I'd like to understand what's really going on when signing in a user with rails/devise.
I've created a minimal rails app, installed devise and created a User devise model.
Everything works fine, and when I log in (using remember me) I get a session cookie just as expected.
Now what's bugging me is : How does rails handle the session informations that the browser is passing through the cookie ?
I'd naively expect some information to be stored in the database, but I don't see where. There's no such thing as session table, no session column in Users, and I couldn't find anything of interest in the tmp dir.
Note that restarting the server wouldn't kill my session. It is of course expected, but now I'm really wondering what kind of magic is happening here ?
in other words : how does the server check the validity of a cookie to authenticate a user ?
Thanks !
The default rails session storage is CookieStore. This means that all the session data is stored in a cookie rather than in the database anywhere. In Rails 3.2 the cookie is signed to prevent tampering, but not encrypted. In Rails 4 it's generally encrypted by default. The fact that it's in a cookie is how it persists across restarts of your server. It also means you can only store 4k of data and you wouldn't want to store anything sensitive in there in Rails < 4. It's best to keep a minimum of data in the session anyway.
You can also opt for storing the session data in the database and only having a session id in a cookie.
This answer I gave the other week has some extra info that might be useful:
Sessions made sense to me before I started reading about them online
Also, the rails api doc for CookieStore gives a nice summary:
http://api.rubyonrails.org/classes/ActionDispatch/Session/CookieStore.html
Trying to figure out how to identify unique users properly with cookies and perhaps coupling that with the public IP.
What's the suggested path to follow in this regard? (I'm open to a standard Rails method or leveraging another Ruby Gem if that's more elegant.)
On the topic of cookies, which is the proper way to retrieve client cookies in Rails 3.x+? I have been using cookies, but it seems that request.cookies also works. What is the difference / preference when using these two? I've seemingly seen request.cookies fail in some instances; but perhaps it was after clearing out the cookies for the app prior to refreshing and working with it in the console.
Also, do cookies have a unique ID that can be utilized to identify clients uniquely?
Essentially my goal is to count visits per unique visitor to a site. I am assuming I will need to compare a unique cookie ID and perhaps an IP, but I'm not sure what would be most kosher in this situation.
Ultimately I need to to understand how to uniquely identify visitors of the site and then store them in a count or number of visits to the site for that visitor.
For your question on the difference between cookies and request.cookies see
http://www.quarkruby.com/2007/10/21/sessions-and-cookies-in-ruby-on-rails#scvr
It's well explained.
I have a Rails's application and i saved user's session in sessions table. It's run on domain example.com
Now I'm developing a CakePHP's application run on subdomain cakephp.example.com. How can i reuse session from Rails's app? Thanks in advance.
Yes it can although I'm not sure why you would want to. Assuming you are using Cookie Store the session is simply base64 encoded.
$rails_session = base64_decode($_COOKIE['_foobar_session']);
Obviously you need to replace the cookie name. Additionally you won't be able to modify the rails session and use it in rails again because there are some security restrictions to tampering with it. You can disable them but I wouldn't suggest doing that.
Another option is to store the session in the database in which case you can access it just like you would for any data.
EDIT: After rereading your question it seems like you would want to read the session in initially like I stated above and use that to create a new session in cakephp.
I am currently experiencing a strange issue with our users being logged out. I haven't been able to reproduce it explicitly.
The Rails application is using the default CookieStore.
My initial hypothesis is that somehow the session data within the cookie, or even the cookie itself is being destroyed. This may be either from a user clearing browser data, or something within the system that has not been caught.
As of now, the authentication system appears to be functioning as intended (Authlogic), and we are not experiencing the issue wide-spread in other components of the application.
I am considering using ActiveRecordStore to see if the problem is resolved. My understanding is the session data would be stored within the database, and if a cookie was being removed - the user would not get logged out.
Are there many known pros/cons to using CookieStore vs ActiveRecordStore?
Why is CookieStore the default when creating a Rails application, and not ActiveRecordStore?
I can answer your last two questions.
You should not use the cookie store if you're storing sensitive data in the session because you want such data to be on the server-side and not on the client.
The cookie store is the default because Rails is giving you a strong hint that you should not be storing lots of data in the session, by virtue of the fact that cookie storage is limited to 4 KB.
I think CookieStore is the default because it is simple. It doesn't require a database table.
CookieStore is not as secure as ActiveRecordStore. With CookieStore, intercepted cookies will give access to a valid session forever, even if you create a new one. With ActiveRecordStore, you can invalidate a session by removing it from the database.
See this blog post: http://www.bryanrite.com/ruby-on-rails-cookiestore-security-concerns-lifetime-pass/
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.