Todd W wrote: > Im looking at Apache::Session and trying to figure out what it does.
It provides shared storage of a hash of data, and gives you a unique ID that you can tie to a user. > From what I > can tell, Apache::Session will only give generic sessions, of which I know > nothing about the user untill they give me information during that > particular session. It's just a storage mechanism. Typically the procedure is that one a user identified herself with some kind of login process, you put her user ID (a primary key to a database table) into the session, and keep it as a key for accessing that data. > I have a table with some basic user information (first name, last name, > address, > phone number, etc...). That's permanent data, not session data. Session data is transient. > What i did was created the two columns, and hoped it would work without > the id column being the primary key. It won't. All of the Apache::Session data is in a blob in the a_session column. It has no access to the other columns. > So now Trying to decide what to do, in a perlHeaderParserHandler Ill > just get an > id from Sys::UniqueID, send it to the browser each request in a cookie or > whatever, then use DBI::Tie to reinstate the session for each request. > (Thinking about it, that sounds easier than Apache::Session anyways) Isn't your user table referenced by a user ID? You have to connect the user ID to a browser somewhere. The normal way to do this is give the browser an ID (the session ID) and then store the relationship with Apache::Session. If you have no other transient data besides the user ID, you can skip Apache::Session and just send a user ID cookie. Make sure you have security in place to prevent people from simply entering another user ID in their cookie and gaining access to another person's information. By the way Tie::DBI is slow. Writing some kind of module for accessing your specific user table would be faster. - Perrin
