Well, I'm not sure what's involved in determining $r->user aside from reading the cookie. It may not make any difference.
Here's a typical pattern for this:
- Fetch the session key from the validated cookie. - Load the session using that key. - Grab the user ID from the session. - Load the user's data based on that ID.
The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user.
Not sure that I quite understand ... what do you mean by "load" the session/user data if it is being done in a handler before content phase? What would you use to store the retrieved data ... pnotes? Also, I am not quite sure of the distinction between session data and user data. Wouldn't session data be intrinsically tied to a user? My session table currently looks like [user_id, session_key, session_data, login_time, last_access_time]. I guess I am currently using the session table to be more of an authentication table, i.e. if you give me a good user_id/session_key ticket that matches what is in the database.
I guess my pattern is:
within PerlAuthenHandler
-Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key.
-Otherwise, if there is a cookie, validate the cookie's user_id/session against the database one stored in the database.
-If either the params or cookie passed muster, set $r->user and return Apache::OK. If the user passed incorrect parameters, redirect to a custom_error form which is the login page. Otherwise, return Apache::OK and do not set $r->user.
within registry scripts: -If $r->user is set, turn on custom pages and load user preferences.
-Mike
