We are currently having a very strange issue that is occurring with a Spree install running on NGINX. Users are reporting issues recovering passwords and once recovered having issues of logging into the site. We have not been able to reproduce this error but know it is certainly happening due to all of the reports from users we are receiving. Also to not is users are able to login when they try a different browser. If the first attempt is in Firefox and then they try Chrome chrome will end up working in a good amount of cases.
Email from user:
"Still not getting through to shop. I have changed my password twice now and when I got to put it in nothing happens. It just refreshes the page and I am left with a blank spot for e-mail and password. "
Errors in the NGINX error log:
cache: [GET /login] miss
cache: [POST /user/sign_in] invalidate, pass
Configuration:
Rails 3.1, Spree 1, passenger-3.0.11, ruby 1.8.7 REE
Any and all answers / suggestions are GREATLY appreciated.
Two rails applications were running on both a domain and a subdomain and the browser had conflicts with the session cookie set in the file session_store.rb that had the same key and would not allow users to login if they had the cookie from sample-domain.com first or shop.sample-domain.com respectively.
Related
I have two rails applications. From one day to another both produce an ActionController::InvalidAuthenticityToken exception. I can call the login page, but when I try to login, the exception raises and in the console I find "Can't verify CSRF token authenticity".
What I tried:
different browsers
I checked out older releases from which I definitely know, that it had been working.
I do not post any code because I do not think that it would help. It must have an external reason, because the problem occurred on two separate apps in the same moment.
The reason was, that I forbid Cookies for localhost in Chrome.
What I can't figure out is, why I had the same problem in Opera, though I did not forbid cookies there.
My application just upgraded to Rails 4 and we're starting to see random InvalidAuthenticityToken errors. I have done a bunch of investigating but not yet found a solution. Anyone know what happened and how to fix it?
Calling out things that appeared in other similar SO questions but do not apply to me:
We call protect_from_forgery with: :exception in ApplicationController, but we were doing this in Rails 3 as well and did not have this error.
I have confirmed these are normal users using the website in a standard fashion; these are not CSRF attempts.
These are not API calls, they are standard web form submissions.
The authenticity token is present in both the form (via Rails form_for or form_tag generation) and in the submitted request.
My sessions should not have an expiration set, since I do not set an expiration time and the Rails default is forever, and my users don't often log in or out (so expired tokens are unlikely, as is "had a tab open, logged into a separate tab, went back to open tag and attempted action").
The csrf_meta_tag was generating the same tokens as my forms and removing it does not help.
My users confirmed they experienced this on at minimum Firefox, Chrome and Safari.
All code is available on Github.
Possibly relatedly: if I change my development secret_key_base in secrets.yml and change my session_store.rb file to use:
Rails.application.config.session_store :cookie_store, key: '_glowfic_constellation_' + Rails.env, domain: 'glowfic.com', tld_length: 2 and restart the server, I am logged out and can reliably experience this error 100% of the time when attempting to log in.
Edit calling out a couple more things:
I can't force clear all sessions because I use cookie stores, but I've already reset the secret_key_base and cookie name in production, which (hard to tell but I think) helped? But did not fix the issue.
The "possibly related" seems to be unrelated, and to have been related to the domain "glowfic.com" not supporting "localhost"; if I use the domain localhost instead, I can't reproduce locally.
Our mobile app recently stopped authenticating properly with our server on our staging and staging2 environments. Fortunately production is fine.
We're using force_ssl in our API's Session and Registration controllers. It was working fine before; not really sure what changed.
What seems to be happening is that our app submits a POST request to either create a new session or user. This request is over SSL, but we get a 301 Moved Permanently with a location identical to the initial request. I believe this redirect is performed via GET and since no routes match a GET to that URL, we then get a 404 Not Found.
I can't figure out why this changed recently and why it's not affecting production.
Turns out it was something having to do with Engine Yard, and an upgrade of our environment solved the problem.
While the problem happens almost always to users in Internet Explorer, it has happened in Firefox and Chrome a few times as well.
The issue is in which users attempt to login and either get a 422 error or are simply re-directed back to the login screen. We have a wildcard cookie, but we recently switched it to targeting www (about 3 months ago) and the previous cookie was set to expire at the end of the session.
We also recently switched to Devise authentication from Restful_athentication in hopes that it would fix the issue, but it doesn't seem to be helping. However, I don't see how these are related as they don't really manage the cookies, Rails does, they just put things in the cookies. I thought maybe the issue was that restful-auth was putting something in that got corrupt under weird conditions, but that apparently was not the case at all
UPDATE
After we switched to Devise, users encountering this problem no longer got a 422 error, but now the page just refreshes and nothing happens. I should also mention that when they enter in their email to retrieve their password (as they think they're entering their password in wrong), it returns that the email is not found in the system.
When they clear their cookies, particularly in IE, they still run into the same problem. I've walked a few users through searching for the individual cookies in Firefox and that has solved the problem. However, simply just going to clear cookies the normal way didn't work. The issue was mainly effecting IE7 users, but seems to be all across the map, with users reporting the issue on Chrome, IE8, Firefox, Safari and Safari for the Ipad.
Also, here's a link to the code for the session_store.rb here and here the host is set in def ensure_domain, which is here
UPDATE 2
I just made a very minor adjustment and it changed it so it always sends a host. I tried logging in every different way on every browser and didn't run into any issues. I'm hoping this helps
UPDATE 3 (LAST UPDATE)
We tried a combination of a few different things, so while I'm not exactly sure what fixed it, my best guess is removing the cache from 4 days to when the session ends/browser closes. While I'm not thrilled about this as I personally dislike having to login every time, I'd rather have the problem fixed (and this issue didn't start occurring until after we changed the cache length to 4 days.)
Sending a host was a mistake and actually made the problem worse for everyone as no one was able to login. Another strange thing was that when looking at the cookies created there were two Session ID cookies, which I would guess were causing the conflict, particularly with IE7. Some users are having to clear their cookies to get logged in still, but at least that seems to be working most of the time.
To any having a similar issue, sorry I couldn't be of more help!
If an HTTPS cookie is set to "secure", it WILL NOT be sent out on HTTP protocal. It is as if it doesn't exist. This sounds like what is likely "stripping out" your cookie.
Cookie basics: If something is worth protecting via HTTPS and you need to track that info afterward (ie, authentication token), it is best to keep it in the HTTPS cookie and only access it from HTTPS.
This is a cookie security issue, and is better discussed at: Secure cookies and mixed https/http site usage
Context: A rails app with authlogic for sigup and login
Setup info: Rails 2.3.2
A controller called posts with an action 'show'.
Upon login, I display the posts/index page.
and when the user clicks on an item, item's details get displayed. Fairly standard stuff.
All of this works fine and dandy both in Development and Production (Apache with Passenger 2.2.5 on ubuntu and mysql) EXCEPT for the following problem in one case:
Problem:
ONLY on Firefox/Safari/Chrome (IE7 is Ok) and ONLY in PRODUCTION,
When the user logs in for the very FIRST time in a new session
(open new browser,type in url), the index page is displayed fine
and when an item is clicked, the user gets mysteriously LOGGED OUT
(current_user returns null).
When you login again, everything is BACK to normal - you can logout and login any number of times and no problem - UNTIL you close the browser and start again.
Any other action besides 'show' has the current_user preserved and works fine.
QUESTION:
How is the user session getting lost on a call like this
posts/id only once - the first time ?
The show action doesn't do anything special.
I have used both ActiveRecord Store and Cookies for Session Management with same behavior.
Anybody got any clues, greatly appreciated!
This might be happening because the user is getting redirected from:
http://yoursite.com to http://www.yoursite.com
Here's a blog that mentions this problem:
http://garrickvanburen.com/archive/rails-cookie-settings-for-cross-subdomain-sessions
To paraphrase the blog:
The fix is to set:
config.action_controller.session[:domain] = '.YOURDOMAIN.COM'
inside of environment.rb (Make sure to prefix it with the .). That will make cookies work for both www.yourdomain.com and yourdomain.com (as well as any other subdomains).
This technique is also discussed here:
Losing session in rails 2.3.2 app using subdomain