Re: Apache::Session and user sessions
Rafiq Ismail (ADMIN) wrote: I'm not sure how often a user will attempt to complete one form through multiple browsers. To be honest I'm not sure that he/she should. There are all kind of forms. An obvious example would be a search. Users often open up multiple windows when browsing a site and do searches in them. If you store search-related data in the session, the multiple windows will interfere with each other. These should be stored in the HTML instead. - Perrin
Re: Apache::Session and user sessions
On Mon, 9 Dec 2002, Perrin Harkins wrote:
> md wrote:
> > My question is with regards to whether I need or
> > should put the submitted data into the session as the
> > user navigates the forms (to create an account). The
> > user will be taken through three forms to create an
> > account. So for instance, form one will ask the user
> > to create a username, password, and provide an email
> > address. Before moving on to form two (billing info),
> > should I put this data in the session, or just go
> > ahead and dump it in the database (after making any
> > nec. checks), since I won't need the info until they
> > actually login? Or should I collect all the info from
> > all three screens by putting it in the session as the
> > user traverses the forms and then put it all in the
> > database at once? I'm currently using the first
> > option. BTW, it is possible for a user to create a
> > free account by hitting form one only, so no harm
> > would come if something happened after form one.
>
> This is really a question of requirements. In systems where all
Agreed.
I have a golden rule for this:
if (( management are annoying and like to know about incomplete
registrations
||
you want one point of varifying input so that designers can
shove in as many intermediary pages as possible)
)
&&
You don't have a ridiculous amount of fields to process )
{
place in session
}
else
{
shove in hiddens.
}
I wouldn't start populating your real tables until the registration is
complete since you may end up with lots of incomplete junk in there and
your form design will be governed by any database constraints placed on
your table (foreign keys, and stuff).
Then again, I sometimes have to bend my golden rules. Fortunately Perl
and Gold both bend easily.
> usually don't store form input in the session because it leads to
> strange results if the user has multiple browser windows open on the
> site, but that may not be an issue for your application.
I'm not sure how often a user will attempt to complete one form through
multiple browsers. To be honest I'm not sure that he/she should. I think
of a form as one process which may remain persistant due to hiddens or a
session. Once the form has been completed or a user has logged in, the
session data used for the rest of the site should probably be unrelated
and populated separately.
That's just my 0.02 EU on a cold Monday evening.
R.
Re: Apache::Session and user sessions
md wrote: My question is with regards to whether I need or should put the submitted data into the session as the user navigates the forms (to create an account). The user will be taken through three forms to create an account. So for instance, form one will ask the user to create a username, password, and provide an email address. Before moving on to form two (billing info), should I put this data in the session, or just go ahead and dump it in the database (after making any nec. checks), since I won't need the info until they actually login? Or should I collect all the info from all three screens by putting it in the session as the user traverses the forms and then put it all in the database at once? I'm currently using the first option. BTW, it is possible for a user to create a free account by hitting form one only, so no harm would come if something happened after form one. This is really a question of requirements. In systems where all information needs to be collected before a valid account can be created, you have to wait until the end to put it in the permanent tables. I usually don't store form input in the session because it leads to strange results if the user has multiple browser windows open on the site, but that may not be an issue for your application. Another question, while not mod_perl related (sorry:), is how to taint check input data like usernames, address fields and email addresses. All info is just put in the database, no unsafe system calls are run. I'm curious as to what characters to limit for usernames in particular. If you're using bind variables with DBI, there is no technical reason to restrict the characters at all. Just make sure you HTML-escape them whenever you display them on a page. - Perrin
Re: Apache::Session and user sessions
--- Perrin Harkins <[EMAIL PROTECTED]> wrote: > Todd W wrote: > > 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. I was reading through the archives and came across this. Everyone was so helpful the last time I had a Apache::Session question (thread "what goes in a session?") so I'm back with another question. The last project I worked on really had no transient data, so the only thing I put in the session was the user id (well, there was one transisent item...current page, so that got put in the session as well). The project I'm currently working on (mod_perl, TT, Apache::Session) is a registration system. Since this is closer to a shopping cart, I would consider the data transisent. My question is with regards to whether I need or should put the submitted data into the session as the user navigates the forms (to create an account). The user will be taken through three forms to create an account. So for instance, form one will ask the user to create a username, password, and provide an email address. Before moving on to form two (billing info), should I put this data in the session, or just go ahead and dump it in the database (after making any nec. checks), since I won't need the info until they actually login? Or should I collect all the info from all three screens by putting it in the session as the user traverses the forms and then put it all in the database at once? I'm currently using the first option. BTW, it is possible for a user to create a free account by hitting form one only, so no harm would come if something happened after form one. Another question, while not mod_perl related (sorry:), is how to taint check input data like usernames, address fields and email addresses. All info is just put in the database, no unsafe system calls are run. I'm curious as to what characters to limit for usernames in particular. Thanks... __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Apache::Session and user sessions
> >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. Okay... That makes sense >>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. Thats what I was looking for. I ran through the code with ptkdb but since I wasnt using it right, it never did a lookup anyway. >>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? Yeah. I said that in the OP but you snipped it. >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. Yeah, Ill relate the users id and a session id when she logs in. "Writing Apache Modules in Perl and C" has some good suggestions about securing the cookie. This all makes good sense after you distinguished the difference between session data and permanent data for me. >By the way Tie::DBI is slow. Writing some kind of module for accessing >your specific user table would be faster. > Okay. Thanks for all your insight. Todd W. _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: Apache::Session and user sessions
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
Apache::Session and user sessions
Im looking at Apache::Session and trying to figure out what it does. What I
want
to do is tie sessions to a particular record in a database table. 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.
I have a table with some basic user information (first name, last name,
address,
phone number, etc...). Apache::Session says I have to have a column named id
and one called a_session. It says that the id column must be primary key,
but
my table already has a primary key, an auto-increment column for the userid.
What i did was created the two columns, and hoped it would work without the
id
column being the primary key. I stuck a 32 character string I got from
Sys::UniqueID in the id column and tried to do:
...
my($dbh) = DBI->connect( MISANet::Util::DatabaseOpts::getOpts() );
my($id) = '3D898BE8C0A80125229B0001';
my(%hash);
tie %hash, 'Apache::Session::MySQL', $id, {
Handle => $dbh,
LockHandle => $dbh
};
$r->content_type('text/html');
$r->send_http_header();
$r->print( "DummyHello,
$hash{firstName} $hash{lastname}" );
...
in a perlHandler where firstName and lastName are columns in the database.
%hash
never gets defined and $! dosent report anything.
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) What do
you guys think? Am I using Apache::Session wrong, or are there better
alternatives than what Ive came up with?
Thanks in advance for the input.
Todd W.
_
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
