I have a rails application and I am using devise for authentication.
When I get logged in successfully on URL http://localhost:5000/,
I try to access http://127.0.0.1:5000/ in the same browser.
I expect to be logged in as soon as I access it on http://127.0.0.1:5000/ but application remains logged out. Whats going on I really cannot understand as I am trying to access both URLs in the same browser?
UPDATE:
my config/initializers/session_store.rb
Rails.application.config.session_store :cache_store, key: '_app'
The fact that you are logged in is store in the session which is stored in a cookie. For security reasons, the browser sends cookies only to the URLs from which the cookie was set.
From the browser's point of view, localhost and 127.0.0.1 are totally different URLs. Therefore the login information stored in the cookie on localhost is not sent to the server running at 127.0.0.1 and therefore the server running at 127.0.0.1 has no information about an existing session on localhost.
UPDATE:
Using the cache_store to store the session doesn't change anything because the information what session in the cache store belongs to the user is still stored in the cookie.
Imaging that your server needs to store all generated sessions somewhere. And if a user comes backs the server needs to know which session belongs to the user. A simplified solution to this problem might be to assign a random number to each session and give the user this number (stored in the cookie). When the user returns the cookie is returned too and that allows the server to load the session by that number.
And a cookie is bound to a domain. This is a security feature of the browser. If it didn't work that way all sessions would be sent to all domains: Google would know if you were logged in to Facebook, every website would know that you have a cookie from your bank...
Related
I need to read cookies set by some different application into my rails application. both the application is running under common SSO (authentication) and when the user successfully authenticated he first redirected to the first application (Node/Express app) which write some data into browser cookies and then when the user clicks on some button which loads my rails application. it will create a rails session. I need to set some variables reading from the cookie set by node/express application.
Assuming your SSO cookie is named "sso_cookie", to read the cookie: cookies[:sso_cookie]. To update the cookie: cookies[:sso_cookie] = 'new-value'.
See ActionDispatch::Cookies.
I have a website freshly deployed on the internal network of a client. I can test it only by remote desktop on a Windows Server 2012.
The website performs SAML authentication: the browser first receives a session cookie from the website, then is redirected to the SAML identity provider, and comes back to the website with the SAML response, where it also sends back the session cookie. This works fine with Chrome, but for some reason IE11 won't send back the session cookie, which prevents the server from accepting the SAML authentication.
I have no idea why IE11 fails to send the session cookie. I have checked in the Network pane in debug tools, and I do get the cookie (though I can't confirm IE is actually storing it) :
Set-Cookie ASP.NET_SessionId=yzk4rdznlg534so2xuxqmuv4; path=/; HttpOnly
Then I am redirected to the identity provider, but when coming back to the website, it doesn't send the cookie. The cookie is HTTP only so I can't check in the console if it is stored or not. I have used the instructions posted here to see stored cookies, and I can't see a cookie for my website at any time (though redirections happen fast, so it could possibly be added and then removed before I have a chance to see it).
I also believe I have explored all possible security and privacy settings to allow everything, to no avail.
In case it's important, the site URL has no dot (it's https://mmr-pp_sef/)
Any idea how I could troubleshoot what is (or isn't) happening?
Well, turns out that it IS related to the URL used (should have checked myself sooner instead of just pointing out that the URL was weird in my question).
Apparently, IE will not store cookies if there is an underscore _ in the host name. This can be verified by modifying your "hosts" file:
Open the file C:\Windows\System32\drivers\etc\hosts (you'll need admin rights)
Add this line at the end and save the file:
127.0.0.1 test_site
Enter the URL http://test_site in your browser (this assumes your web server listens on 127.0.0.1)
Observe that IE won't store any cookie.
The only workaround I have at this time is to use another host name, that does not contain an underscore, such as test-site.
We used to store session with action record and now is moving it to cookies store in Rails 4. We understand that with cookies store, all session data is stored in client side cookies besides secret token and plan to only store ids in session. Here are a few questions:
After a user logs out, are all session data (for example, user_id and user_group_id) still preserved in client cookies for next login?
If a user is assigned a new user_group_id for example, will the old user_group_id stored in client cookies still prevail and blow off the app with user next login? There are online posts talking about app blow-off when session object gets changed on server but can not be updated accordingly on client side (unless change of secret token).
Besides to 4kb size limit and ids (session) only with cookie store, are there other things (or disadvantage) to consider when moving session from db to cookies store?
Here is the low down on cookie store. First off, everything in a cookie is there permanently once it's set or until the user deletes the cookie manually somehow. This means, that if you set user_id and user_group_id, it's there for good in the cookie until updated or deleted. This is different from a session since the session is like ram on a computer, once the browser is closed, the session closes with it as well as all of it's data.
So, this means that when you log out your user, you need to specify that their cookie empties anything you don't wan't it to have. When your user logs in, you set anything that you want the user to have while they are logged in. So, since the session and cookie are separate things completely, they never interact together unless you choose to make them. So your session will never dump its self into the cookie store unless you make it do that.
Every time your users go to your site, you could have a single handshake that makes sure that the cookie matches the db if necessary. Otherwise, you could have differing data what only gets updated on login or what not and without the handshake, the user would have to keep logging in to make sure they are still valid which defeats the purpose of having a cookie in the first place.
The downside of client side cookie storage is security concerns. Depending on how you use the cookie to store data, a person could hijack somebodies cookie on your site and pretend they are them. This can be avoided by careful design, but just assume that whatever is in your cookie store is fair game to everybody so use it carefully and for only non secret data.
Hope this helps!
In my scenario I have logged into an application and am calling a c# function to create a session in my Identity application. Then I am accessing an service provider application which will redirect to identity application. but here the session I have created is not been recognized and Identity asks Login.
Is my logic correct. or need any remedy?
thanks,
Anish.
It should work but there are a few reasons why your session might be lost:
The session cookie is expiring - how long before user is redirected back? Check your session timeout
You are using cookieless sessions - the session identifier in the URL is lost after redirect
You are using the default in-memory session provider and you have more than one webserver - you are redirected to a different host that doesn't recognize your session
If it is none of these, use browser developer tools to check the session cookie and see why it isn't being sent.
I'd appreciate any thoughts/insight any of you might have on this...
I have two domains running the same applications e.g. mysite.com and mysite.org and I have a requirement that when a user logs into mysite.com then he should also be logged into mysite.org. Obviously, I can't set the cookie on another domain but I want to come up with a reasonable, secure solution. I think I have a solution (on paper), but I'd just like some feedback on how to improve & secure it.
My sessions table looks like this currently:
id: auto-incrementing; only used for by ActiveRecord
uuid: Universally Unique Identifier used for session lookup
user_id: the user this session belongs to
user_ip_address: the user's IP address
created_at: self-explanatory
updated_at: self-explanatory
My current logic for authenticating on one domain:
User tries to access mysite.com/some_protected_info; they are no authenticated so they are redirected to the login page (the referral URL is stored in a cookie)
User successfully authenticates on mysite.com; a session is created in the DB; a cookie for the mysite.com is created; user is redirected to the referral URL in the cookie i.e. mysite.com/some_protected_info.
My proposed logic for authenticating on two domains:
User tries to access mysite.com/some_protected_info; they are no authenticated so they are redirected to the login page (the referral URL is stored in a cookie)
User successfully authenticates on mysite.com; a session is created in the DB; a cookie for the mysite.com is created; user is then redirected to a mysite.org e.g. mysite.org/login/special
The login controller's special action looks up the session, sees that it's valid and sets the cookie on the mysite.org and redirects back to another controller action on mysite.com.
Given that the user is authenticated on mysite.com (and presumably mysite.org) the user will be redirected back the referral URL (mysite.com/some_protected_info).
Of note:
- Both sites are using SSL.
- Both sites are using the exact same code (mongrel instances) - the Apache config makes it accessible via different domains i.e. the config.action_controller.session settings on both domains are exactly the same.
Questions:
In (2) should I pass in the UUID via SSL or is that a security concern? Should I generate a new, random, temporary ID to lookup the session?
In (3) should I be passing the referral URL around (mysite.com/some_protected_info) or is it safe just to redirect back to the value of the cookie on mysite.com?
Any gotchas? Special situations that I'm overlooking?
This is not a real answer but if you own the two domains you can set your cookies using cookies cross domain policy:
for example you can create a crossdomain.xml on yourdomain.com:
<?xml version="1.0" ?>
<cross-domain-policy>
<allow-access-from domain="yourdomain.org" />
</cross-domain-policy>
A simple design for a sign-on system that works across domains depends on their being a single point for authentication that other domains can use to verify session information.
Typically the sign-in mechanism is an HTTPS protected page that is capable of verifying credentials and issuing a session ID that can be verified remotely. In practice one domain will forward the visitor to the sign-in page for authentication, then the sign-in process will redirect the visitor back to the original site with some kind of session-ID parameter passed along that can be assigned to a cookie by the original site.
For applications with only moderate security requirements, the session ID value can be encrypted or hashed using a "secret key" known to both the sign-in system and the other domains. This is used to prove that a user's session ID has been issued by the sign-in system and isn't just arbitrary. This is not unlike hashing a password with a salt for verification purposes.
While UUIDs may seem sufficiently unique, the generator may produce predictable numbers, or numbers with insufficient randomness. That is why sending a "signing" value is useful to preclude spoofing.
The idea you have seems fairly solid, but the details matter. It may be worth studying things like OpenID for how they handle session authentication via their protocol.