Proper user of Session

[Morten Snedker]

A user enters a password. Via stored procedure i lookup that (unique)
password. If it is found I save the userID to a Session("userID") for
later use. I use no other saved variables than this one.

If Session("userID") is not set, trying to access any other page
results in a response.redirect to the default.aspx - this I find to be
a simple and useful way of handing user access.

My collegue finds this improper use of Session. "What if user starts
entering data and leaves for lunch or a meeting - when he comes back
the session has run out". That is the only valid argument he can give
me - an okay argument.

He believes the proper way is to use a QueryString instead. My argue
is that I don't want the user to be able to others data just by
entering the proper value in the querystring trough the browsers
address line.

Also I can see the advantage of querystring if a long list/table
(multiple records) si clicked to show detailed information (one
record). But this is not the case right now.

What pros and cons does Session and QueryString have in comparison? Or
is it even senseless to compare these?

Regards /Morten

[Ray Costanzo]

Stick with your feelings and ask your friend if he's ever used the Internet
before. Yes, that's right, if a user goes to lunch, his session will expire
(you can adjust this timeout). But this is how many, many, many, many, many
sites work! You can offer the option of "remember me" and save the person's
login information in cookies. Then, at the firing of a new session, you can
see if login information was sent via cookies and log the person in that
way. If not, redirect him to the default page. But, no matter what, don't
listen to your friend! :]

Ray at work
"Morten Snedker" <morten_spammenot_ATdbconsult.dkwrote in message
news:un********************************@4ax.com...

>A user enters a password. Via stored procedure i lookup that (unique)
password. If it is found I save the userID to a Session("userID") for
later use. I use no other saved variables than this one.

If Session("userID") is not set, trying to access any other page
results in a response.redirect to the default.aspx - this I find to be
a simple and useful way of handing user access.

My collegue finds this improper use of Session. "What if user starts
entering data and leaves for lunch or a meeting - when he comes back
the session has run out". That is the only valid argument he can give
me - an okay argument.

He believes the proper way is to use a QueryString instead. My argue
is that I don't want the user to be able to others data just by
entering the proper value in the querystring trough the browsers
address line.

Also I can see the advantage of querystring if a long list/table
(multiple records) si clicked to show detailed information (one
record). But this is not the case right now.

What pros and cons does Session and QueryString have in comparison? Or
is it even senseless to compare these?

Regards /Morten

[Mark Rae]

"Ray Costanzo" <my first name at lane34 dot commercialwrote in message
news:O6**************@TK2MSFTNGP03.phx.gbl...

But, no matter what, don't listen to your friend! :]

Most definitely!

[Peter Bradley]

Your friend is most definitely wrong - but why are you not using forms
authentication? That way you can use security attributes to keep users out
of places where they should not be, and you don't need to maintain data in
the Session at all.

Sorry if I've misunderstood you and that is actually what you are doing.

HTH
Peter

"Morten Snedker" <morten_spammenot_ATdbconsult.dkwrote in message
news:un********************************@4ax.com...

>A user enters a password. Via stored procedure i lookup that (unique)
password. If it is found I save the userID to a Session("userID") for
later use. I use no other saved variables than this one.

If Session("userID") is not set, trying to access any other page
results in a response.redirect to the default.aspx - this I find to be
a simple and useful way of handing user access.

My collegue finds this improper use of Session. "What if user starts
entering data and leaves for lunch or a meeting - when he comes back
the session has run out". That is the only valid argument he can give
me - an okay argument.

He believes the proper way is to use a QueryString instead. My argue
is that I don't want the user to be able to others data just by
entering the proper value in the querystring trough the browsers
address line.

Also I can see the advantage of querystring if a long list/table
(multiple records) si clicked to show detailed information (one
record). But this is not the case right now.

What pros and cons does Session and QueryString have in comparison? Or
is it even senseless to compare these?

Regards /Morten

[Larry Bud]

My collegue finds this improper use of Session. "What if user starts

entering data and leaves for lunch or a meeting - when he comes back
the session has run out". That is the only valid argument he can give
me - an okay argument.

Yep, that's a good thing... what if the user leaves for the day and
remains logged in so the cleaning woman can delete every row of data?

I would do a couple of things, though. Forward the user to a page that
explains that their session has run out due to inactivity for X number
of minutes, so they know what the hell is going on. 2) Make sure no
form take so long to enter that the session runs out while they're
actually working.

If users bitch and moan about a 20 minute session, you can always bump
it up. On one app, we have ours set to 60 minutes because a user will
often be on the phone with a customer while accessing the app, and will
be flipping back and forth between the app and an Excel sheet.

He believes the proper way is to use a QueryString instead. My argue
is that I don't want the user to be able to others data just by
entering the proper value in the querystring trough the browsers
address line.

The QS is no security whatsoever. You're right, he's wrong.

[Morten Snedker]

On Mon, 15 Jan 2007 14:41:05 -0000, "Peter Bradley"
<pb******@uwic.ac.ukwrote:

>Your friend is most definitely wrong - but why are you not using forms
authentication? That way you can use security attributes to keep users out
of places where they should not be, and you don't need to maintain data in
the Session at all.

I'm fairly new to ASP.NET and I've found out about forms
authentication too late. We're entering test phase first coming
Monday, so I'm on a tight schedule.

I consider the current security to be effecient enough. It is a closed
system with 2,500 known users.

Thanks for your reply.

/Snedker

[Peter Bradley]

I consider the current security to be effecient enough. It is a closed

system with 2,500 known users

Worst type. Nearly all crackers are internal.

I'd change it - but I'm not you so YMMV.
Peter