On Oct 6, 2006, at 2:58 AM, Jani Tiainen wrote: > > Yes they do. Authentication is a concept. Not a single mechanism. And > cookie is one possibility (see below). > > Username - password pair is one form of authentication. Certificate > challenge, kerberos challenge. RSA keys, encryption keys, public > private > keys... All authentication methods, very different still can be > used as > authentication methods.
Notice that none of these are HTTP cookies. The actual authentication check is done by something else. In the case of a default Trac setup, this is HTTP authentication done by the server (or anything else that will populate the REMOTE_USER variable). > > Some webapps use store authentication information (username,password, > sessionkey etc.) in cookie. That's why apps have "remember me" > checkbox > or equivalent (eg. almost forum apps does). It remembers you over web > browser session and saves you typing your login information everytime > again and again. I certainly hope no webapp stores the actual credentials in a cookie, though I sure there are some. Generally the way this works (and this is almost verbatim the way Trac does it) is a session number is assigned to you, and is tagged to the username you logged in with. This session number is then given to you as a cookie. The next time you visit the site, it sees this session number, and re-associates that request with the previous username. > > In this case if you have correct cookie, you are authenticated. Right? > Isn't that authentication then? Your first time authentication method > might be different, like in this case it might have been username - > password combination. In this case your previously anonymous request is given authorization to use your credentials and anything that goes with them, however no actual authentication check has been performed. I suppose you could call this a very degenerate case of authentication, but I don't know of many people who do. Authentication is generally when a user provides a name and a set of credentials, and the system confirms that the name given is that of the user. Cookie-based sessions are more of a blind leap of faith, there is much of a way to verify that the session ID you are providing is yours (see also: check_auth_ip in trac.ini). > > ... and to continue with cookies, there is actually two types of > cookies: session cookies and persistent cookies. These are actually identical. A "session" cookie as you called is simply a cookie with no expiry date given (as defined in RFC 2109). A cookie is simply a name/value pair, what you put in it is entirely up to the developer. Trac keeps no settings (or anything other than opaque sessioning values) in a cookie. All of that is kept server- side in the database. > > Session cookies are temporary, deleted after session is over (browser > closed) and usually don't contain application spesific information > instead of identifying information. > > Persistent cookies are permaent, kept over sessions and usually > contain > identifying information, maybe some settings etc. that application > want > to keep up. > > Long lecture, hope that this clarified thingies.. Hope this clarifies you clarification. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users -~----------~----~----~----~------~----~------~--~---
