Re: Apache::Session and user sessions

[md <my...@yahoo.com>]

--- Perrin Harkins <pe...@elem.com> 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

[Perrin Harkins <pe...@elem.com>]

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

["Rafiq Ismail (ADMIN)" <ra...@joshua.dreamthought.com>]

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

[Perrin Harkins <pe...@elem.com>]

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