I noticed a similar issue when running integration tests against a Rails 2.3.8 app using Authlogic. In my case, I am using Cucumber & Webrat to test the app's API which authenticates via basic authentication. I noticed that the first request would run fine, but all subsequent requests would error out in the middleware stack. Turns out it was coming from the CookieStore; switching to the AR SessionStore fixed the problem.

You broke backwards compatibility with 2.3.5 - was that intentional? Do you have any docs on what versions work with different versions of rails?

No there are no guarantees authlogic 3 will be backwards compatible. That is the point of the major version bump. Any 2.1.X will be backwards compatible.

Thanks Ben. This ensure us that Authlogic 3 is backward compatible to Authlogic 2 and won't break our existing application when we upgrade.

This broke my rails 2.3.4 project, FWIW (fix: downgrade to 2.1.3)

Not a rewrite. I have 3 goals:

1. remove all validations
2. use active model as much as possible
3. create a standard interface for various type of authentication, to provide a nice clean api to add other types. So out of the box you get params, cookies, and sessions. And adding things like facebook auth, openid, etc will use the same api.

I'm sure there will be other improvements along the way, but thats the road map.

Thanks Ben. Will Authlogic 3 be a complete rewrite from scratch? Do you have any estimate plan for Authlogic 3?

I meant to say I will release a 2.1.5

2.1.4 is to run smoothly on rails v2.3.6. Authlogic 3 will be compatible with rails 3. I will release a 2.3.7 with deprecation notices and what not.

What is the plan for 2.1.4?

FYI: I had issues with AuthLogic not logging out when I had Safari in Private Browsing mode..

It may be related to Rails sending no "Cache-Control: private" on redirect_to but still sends the Set-Cookie header which in turn MAY become cachable. Besides this being a security problem, it becomes especially problematic with :cookie_store because that carries the complete session data instead of only some hash which points to session data. Overwriting redirect_to_full_url to send headers["Cache-Control"] = "private" fixed most of the issues I observed with any auth mechanism.

BTW, I don't like using ActiveRecord store because it puts load on the db for session-related work. There are two downsides: #1 extra db reads and writes for every page view #2 stale sessions building up in the db which need to be purged periodically. Neither of these is a big deal but they build up when you get high traffic.

Typically, memcache is a better match for session storage since sessions are transient. But if your site wants sessions to last for weeks and weeks then persistent db storage might be a better match.

We experienced the same issue with Mongrel, Rails 2.3.4 and a Redis-based session store. We are using per-account subdomains which adds confusion to the cookie issues. In our case, logout did not work for IE. Firefox was ok though.

I believe that the problem is with the headers returned to the client on logout. It seems that IE7 keeps a session cookie around after logout that authlogic does not intend for it to keep. This cookie has the authlogic persistence token which matches to the users table (not user sessions) causing the client to automatically re-login after logout.

To determine the source of the problem, we temporarily switched to activerecord based sessions. By looking in the database, could see that the server-side correctly logged out the client in the session store. But even though the data was removed from the server's session store, the client would be logged back in automatically on the next page view after the logout action. Therefore it had to be caused by cookies stored in the browser.

At first, clearing cookies in IE7 did not seem to log the user out. But then we found that IE7 does not actually clear session cookies when you tell it to using the options menu. Only when we used the developer toolbar for IE7 could we actually remove the cookies and then the client would not automatically re-login. This IE7 bug is besides the point, the point is that the source of the problem is that the browser keeps the authlogic persistence token around after logout.

SOOOOO, we ended up clearing the authlogic persistence token in our users table on logout. Even though this has the downside mentioned by binarylogic it is the only way to be sure of logout without diving into complicated debugging of browser-specific session cookie peculiarities.

Hope this helps someone out there.

Not working for me at spokt.com: Rails 2.3.4 and Passenger 2.2.5. I'll try the ActiveRecord Session store.

   # The string of the model name class guessed from the actual session class name.
   def guessed_klass_name
     guessed_name = name.scan(/(.*)Session/)[0]
     guessed_name[0] if guessed_name
   end

how to handle the Null exception, so I think the method should be defined as :

   # The string of the model name class guessed from the actual session class name.
   def guessed_klass_name
     guessed_name = name.scan(/(.*)Session/)[0]
     if guessed_name 
         guessed_name[0] 
     else
         klass_name
     end
   end

Still broken for me on Rails 2.3.4 and Passenger 2.2.5. Probably going to switch to some other session store.

I think this warrants a new release. ;-)

As someone who has also submitted a single character patch to an open-source project's documentation, I feel your pride. ;-)

Epic.