Hi Rob,

I agree with your recommendations. If only life was
that simple this time ;-)
The application has already been built, and they are
not expecting a lot of visitors. (It's a small
business to business site). So recommending to "do it
all over again and this time right" is unfortunately
not an option. 
It will take too much time and money to rebuild the
app to store its state in a database. For the future,
they "promised" to keep that in mind, but the budget
simply doesn't allow it now. (although if it takes me
too long to figure out what to do, it might be cheaper
for them to have parts of the application rebuild
anyway ;-))

Thanks for sharing your thoughts on this.

Imar


--- "Morgan, Rob" <Rob.Morgan@o...> wrote:
> I'm stepping into this a little late, so ignore if
> my response if it doesn't
> apply.
> 
> This is probably what I would do.
> 
> I would turn off the session state for the web.  I
> wouldn't use any
> global.asa.  I wouldn't use any object that will
> store specific information
> on a single server. If I did all that I could put my
> application on as many
> servers as I wish.  Using more then one server for
> my application will make
> up for any speed performance hits I may take because
> I'm doing more database
> calls to make up for the missing objects.  It also
> allows a companies
> application to grow fast it the needs arises,
> without rewriting any code.
> 
> Create a cookie and generate a unique ID for the
> users that's using the
> secure site. Store the unique ID in the database and
> make sure it matches a
> cookie when a user logs into the secure site.  this
> way the unique id in the
> cookie must always match the database unique id in
> order to access the
> secure site. If at any time the IDs do not match
> then the user can't access
> he secure site or a new ID must be generated.  When
> the users signs out of
> the secure site, delete the database unique ID. If
> the user doesn't sign off
> then have the cookie expire every day. If your not
> using logins then just
> change the cookie ID according to which site they
> are using.
> 
> 
> This is just my idea..
> 
>