2

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!

Mischa
  • 42,876
  • 8
  • 99
  • 111
adamwstl
  • 338
  • 3
  • 12
  • Can you post up your code how you're trying to expire them? – 2potatocakes Mar 22 '11 at 22:17
  • Here's the code for the session_store.rb: http://pastie.org/private/ao9nylhul1ioqjcmnyal2g and here's the host is set in def ensure_domain, which is here: http://pastie.org/private/snqidzyiktweex1bfawg – adamwstl Apr 04 '11 at 21:18
  • Some of our user sites have custom domains, which is the code used in the controller above. – adamwstl Apr 04 '11 at 21:20
  • Have you some log where the 422 is return to your users ? – shingara Apr 05 '11 at 10:51
  • Have you override the controller SessionController from devise ? – shingara Apr 05 '11 at 10:52
  • Ever since we switched to Devise, users are no longer getting a 422. Now when they hit login, it's like the page just refreshes. After that, if you look at the Cookies for the page, there are two Session cookies, which seems to me is causing the issue. – adamwstl Apr 05 '11 at 15:20
  • Also, the login page is https but the user is then re-directed to the dashboard which is http – adamwstl Apr 05 '11 at 15:20
  • is there some caching mechanism you use that could possibly ignore or strip the cookie(s)? – Marian André Apr 08 '11 at 11:30

1 Answers1

0

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

Community
  • 1
  • 1
StarPilot
  • 2,246
  • 1
  • 16
  • 18