Browse files

Add note about rails cookie store bug for sessions.

  • Loading branch information...
1 parent 8c8e079 commit 4732d057b370a9103f38c375d8323aaa62a5525f @binarylogic binarylogic committed Apr 25, 2009
Showing with 20 additions and 1 deletion.
  1. +6 −1 README.rdoc
  2. +14 −0 lib/authlogic/test_case.rb
@@ -29,7 +29,7 @@ You can also log out / destroy the session:
* <b>Documentation:</b>
* <b>Repository:</b>
* <b>Live example with OpenID "add on":</b>
-* <b>Live example repository with tutorial:</b>
+* <b>Live example repository with tutorial in README:</b>
* <b>Tutorial: Reset passwords with Authlogic the RESTful way:</b>
* <b>Bugs / feature suggestions:</b>
* <b>Google group:</b>
@@ -38,6 +38,10 @@ You can also log out / destroy the session:
If you find a bug or a problem please post it on lighthouse. If you need help with something, please use google groups. I check both regularly and get emails when anything happens, so that is the best place to get help. This also benefits other people in the future with the same questions / problems. Thank you.
+== Session bugs (please read if you are having issues with logging in / out)
+In some older versions of Rails there is a known issue with sessions using cookie store. This is most likely your problem if you are having trouble logging in / out. This is *not* an Authlogic issue. This can be solved by updating rails or using an alternative session store solution, such as active record store.
== Authlogic "add ons"
* <b>Authlogic OpenID addon:</b>
@@ -203,6 +207,7 @@ What inspired me to create Authlogic was the messiness of the current authentica
2. <b>Easier to stay up-to-date.</b> To make my point, take a look at the commits to any other authentication solution, then look at the {commits for authlogic}[]. How many commits could you easily start using if you already had an app using that solution? With an alternate solution, very few, if any. All of those cool new features and bug fixes are going to have be manually added or wait for your next application. Which is the main reason a generator is not suitable as an authentication solution. With Authlogic you can start using the latest code with a simple update of a gem. No generators, no mess.
3. <b>It ties everything together on the domain level.</b> Take a new user registration for example, no reason to manually log the user in, authlogic handles this for you via callbacks. The same applies to a user changing their password. Authlogic handles maintaining the session for you.
4. <b>No redundant tests.</b> Because Authlogic doesn't use generators, #1 also applies to tests. Authlogic is *thoroughly* tested for you. You don't go and test the internals of ActiveRecord in each of your apps do you? So why do the same for Authlogic? Your application tests should be for application specific code. Get rid of the noise and make your tests focused and concise, no reason to copy tests from app to app.
+5. <b>Framework agnostic</b>. Authlogic can be used in *any* ruby framework you want: Rails, Merb, Sinatra, Mack, your own framework, whatever. It's not tied down to Rails. It does this by abstracting itself from these framework's controllers by using a controller adapter. Thanks to {Rack}[], there is a defined standard for controller structure, and that's what Authlogic's abstract adapter follows. So if your controller follows the rack standards, you don't need to do anything. Any place it deviates from this is solved by a simple adapter for your framework that closes these gaps. For an example, checkout the Authlogic::ControllerAdapters::MerbAdapter.
5. <b>You are not restricted to a single session.</b> Think about Apple's, where they need you to authenticate a second time before changing your billing information. Why not just create a second session for this? It works just like your initial session. Then your billing controller can require an "ultra secure" session.
6. <b>Easily extendable.</b> One of the distinct advantages of using a library is the ability to use it's API, assuming it has one. Authlogic has an *excellent* public API, meaning it can easily be extended and grow beyond the core library. Checkout the "add ons" list above to see what I mean.
@@ -35,6 +35,20 @@ module Authlogic
# Authlogic::Session::Activation::NotActivatedError any time you try to instantiate an object without a "connection".
# So before you do anything with Authlogic, you need to activate / connect Authlogic. Let's walk through how to do this in tests:
+ # === Fixtures / Factories
+ #
+ # Creating users via fixtures / factories is easy. Here's an example of a fixture:
+ #
+ # ben:
+ # email:
+ # password_salt: <%= salt = Authlogic::Random.hex_token %>
+ # crypted_password: <%= Authlogic::CryptoProviders::Sha512.encrypt("benrocks" + salt) %>
+ # persistence_token: <%= Authlogic::Random.hex_token %>
+ # single_access_token: <%= Authlogic::Random.friendly_token %>
+ # perishable_token: <%= Authlogic::Random.friendly_token %>
+ #
+ # Notice the crypted_password value. Just supplement that with whatever crypto provider you are using, if you are not using the default.
+ #
# === Functional tests
# Activating Authlogic isn't a problem here, because making a request will activate Authlogic for you. The problem is

0 comments on commit 4732d05

Please sign in to comment.