-passwords.
-
-A downside to this module is that it does not use a session to
-preserve state so get_pass_by_user has to happen on every request (any
-authenticated area has to verify authentication each time). A plus is
-that you don't need to use a session if you don't want to. It is up
-to the interested reader to add caching to the get_pass_by_user
-method.
+passwords. Or you can completely replace the cookie parsing/generating
+and let Auth handle requesting, setting, and storing the cookie.
+
+A theoretical downside to this module is that it does not use a
+session to preserve state so get_pass_by_user has to happen on every
+request (any authenticated area has to verify authentication each time
+- unless the verify_token method is completely overridden). In theory
+you should be checking the password everytime a user makes a request
+to make sure the password is still valid. A definite plus is that you
+don't need to use a session if you don't want to. It is up to the
+interested reader to add caching to the get_pass_by_user method.
+
+In the end, the only truly secure login method is across an https
+connection. Any connection across non-https (non-secure) is
+susceptible to cookie hijacking or tcp hijacking - though the
+possibility of this is normally small and typically requires access to
+a machine somewhere in your TCP chain. If in doubt - you should try
+to use https - but even then you need to guard the logged in area
+against cross-site javascript exploits. A discussion of all security
+issues is far beyond the scope of this documentation.