session variable dropping....

[BigDaddy]

When a user logs in, I put their id # in a session variable. I have a user complaining now, that when she attempts to do an update or add a record on my page, that when she hits submit, it kicks her back to the login page.

What has to be happening is that the first thing on the page is my "sessioncheck" page, which checks for her id # in the session variable. If it exists, great, it allows the update or add to happen, if not, it requires a login.

Here's the wierd thing:

She has to login, then maneuver between no less than 5 pages that all have teh sessioncheck routine on them, before she gets to the page to add/update a record. I have heard that if cookies are not enabled, session variables won't work, but is there a setting of some sort client side (or something server-side) that might cause the user's session variable to drop suddenly?

I can use her login on my machine and do an update, as well as any machine in my building, and I can login with a different user and do it. She is the only one who has complained about it, but I hate to go back to the user and tell her that it's all on her side, without checking it out thoroughly.

I also have not changed either of the 2 pages in question in probably 6-8 weeks. She just started having the problems yesterday.

[IdentityCrisis]

Ahhh the dredded Session dropouts...

If cookies are diabled, Session variables in ASP will also be disabled requiring your user to log in (all the time.)

In Internet Explorer, you can enabled "Per-Session" cookies, which will allow Session variables to work properly.

As of yet, I do not know if Netscape has added this functionality...

[IdentityCrisis]

I'm using IE 6, but I believe you can do this in IE 5+
[list=1]
Go to the Tools menu and hit Internet Options
Click on the Privacy tab
Under Settings click on the Advanced button
Check the Override Automatic Cookie Handling checkbox
Check the Always Allow Session Cookies checkbox
Hit OK, the hit OK again, and you're done!
[/list=1]

[IdentityCrisis]

I just checked Netscape 7... can't find enabling of per-session cookies anywhere... so, you have to either require your users to accept all cookies, or use IE and just accept Session Cookies

[BigDaddy]

That was my first thought. Question though: If they have to log in, and go through at least 3 pages before they get to the page in question--each one checking their session variable, then it must be enabled already, right?

I also checked my own settings, and I'm not specifically accepting session cookies myself.

[IdentityCrisis]

Yes, either that or there's a problem with the code that checks the Session variable...

[BigDaddy]

That's the wierd thing. I tested it with my machine, and 2 others in the office, as well as my machine from home--outside the network, and they all work. I even tested this specific user's login from the machines in my office, and had no problems.

I'm really beginning to think it has to be her specific machine.

[IdentityCrisis]

Try it on the other machines after disabling cookies...

then try it when you enabled Per-Session cookies only...

Sometimes you need to go through exhaustive testing for the smallest little bugs. I know what it's like, I've been in Web Development for over 5 years now...

[BigDaddy]

Got a chance to actually talk to the user. I'm thinking she's not the most internet savvy person in the world. :rolleyes:

The session timeout is an hour. After she times out, she would attempt to add a member to her group, at which point, it would kick her out to the login page. Now, I'm thinking the intuitive thing to do at this point is to log in, and go back to the add page...right? No. She clicked the "back" button to go back, and clicked "add" from there, then wondered why it would not allow her to add a member, and instead forced her to log in first.

There was nothing wrong with my code. It was all user-error.


Thanks for the suggestions on how to fix it though. I'm sure if it was my problem we'd have figured it out. :D

[IdentityCrisis]

hehehe .. well, ok....

if ever you run into a problem like that though... all those instructions about "Per-Session" cookies are completely correct... so... don't discount it cause I spent a good 10 minutes writing all that garbage :P hehehe

[BigDaddy]

I appreciate it...I really do. I did all kinds of testing with it, and went into it on my machine, as well as others around. I'm sorry for making you go on a wild goose chase.

Dang, I wish they would have told me this was what they were doing...

[IdentityCrisis]

hehe .. no worries... I was bored anyways

[whammy]

Wow, that's amazing Keith. ;)

Not really, but that shows you what you have to deal with sometimes.

Not to mention the other end of the spectrum - people that think they know everything but don't actually develop the application - which usually ends up like the situation above. ;)

Sometimes it's really good if you can talk to the user/client directly in the FIRST PLACE, that way you know what's really going on. But you know as well as I do that won't ever happen with any type of corporate politics involved.

I'm actually quite amazed that someone who was asked to login repeatedly would report this as an error. DUH perhaps?

With that type of person you have to (gently) explain to them that the login screen is there for a reason. ;o)

[BigDaddy]

Yeah....it kinda surprised me. I had been depending on the acct manager to translate between me and the user (you know how that goes...) and didn't realize it was just a case of the user being not very internet savvy.

Oh well.....

[raf]

Maybe ad a (large) message like
"You are automatically logged out, because you did not request any pages in the last 15 minute. Please log in again. <login><more info>"

That's what i always do...

[BigDaddy]

Heh.....that's the funny thing. There was a line saying that. She just didn't bother to read it.


Anyway, I've since made it a larger font, more noticieable. I'm considering a pop-up, but I despise pop-ups.

[whammy]

Maybe a series of alerts...

alert("You have been logged out!");

alert("You MUST login again for anything on this site to work!");

lol

[BigDaddy]

:) I'll flag her specific login id # to do some more "assertive" login reminders. Yeah...

[whammy]

I was just kidding, actually. ;)

[fractalvibes]

perhaps hit her on the nose with a rolled up newspaper next time and scold.....!?!
Bad, user....Baaaaad User!

fv

[Roy Sinclair]

PEBKAC - Problem Exists Between Keyboard And Chair

[BigDaddy]

I'm still convinced it's a user issue, but she complained this morning that she logged in, waited a few minutes, and tried to do an update...but it kicked her out again.

My session.timeout is set to 120. I know that's a really long time, but....

Geez....this wasn't an issue until yesterday. It's kinda frustrating, really. I still think it's user error. I've logged in with her username and sat for 10 minutes, then tried an update....no problem. I think maybe she needs to put down that pipe.

[fractalvibes]

Sounds like maybe you should just go to her desk and observe for a while....

fv

[BigDaddy]

I would, but she's in Kansas, I'm in Nebraska.

[IdentityCrisis]

I would do one of two things...
1) Go to Kansas and cuff her upside the head...
2) Suggest that she checks her cookie settings as I had pointed out in my first reply (way back when...)

p.s. don't actually try #1... you'll be charged for agrivated assault :p

I'm pretty sure the per-session cookies thing might actually be the problem... or at least... it sounds like it from my chair in Ontario :D

Peace

[raf]

BigDaddy,

Can you check the logfiles of the server? Do you have a table or so with active sessions? It's always safer to take care of the session-management yourself since you then don't need to worry about session-cookies etc.

Does anyone know if "incorrect" timesetting on the clientmachine has any influence on session-expiration ?

[IdentityCrisis]

Originally posted by raf
Does anyone know if "incorrect" timesetting on the clientmachine has any influence on session-expiration ?

It shouldn't, seeing as the session-management is all done on the server anyways.

[BigDaddy]

Originally posted by raf
BigDaddy,

Can you check the logfiles of the server? Do you have a table or so with active sessions? It's always safer to take care of the session-management yourself since you then don't need to worry about session-cookies etc.

Does anyone know if "incorrect" timesetting on the clientmachine has any influence on session-expiration ?


Not sure what log files you're referring to. A table with active session?

[IdentityCrisis]

I was a little confused by that message too raf... although, I think I understand what you mean now...

I think raf is suggesting that instead of using Session variables (which are like cookies), you keep all of the session management stored in a table in the database (maybe call it, SessionTracking) or something like that... There you would store the logged in user, their details, etc. etc. etc.

[raf]

BigDaddy,

Sorry it's confusing. If you can acces the logfiles you can check out the request that user made. You need her IP of course. But you could arange with here to have a 'guided session' or print the IP or session.sessionID on the page that signals the timeout and then ask here to send it to you OR you could pull it from a table in your db.

That is, if you got such a table.
It's very usefull to set up a table where you register the sessioninformation. ASP sessionID (not to be used as primary key in this table !!), the IP, the username, start of session, time of last request, ...
(Of course you need to vacume this table from time to time to prevent it from getting to large)

This way, you can check if that user is logged in (to prevent multiple clients log in with the same user), check when they made the last request, even if the session has timed out, and echo that back to them. (on you session_onend sub of the global.asa, you need to have some code to update the db before the sessionobject is destroyed). You can store a key to this sessiontable inside a cookie (where you explicitely set the expirationdate so that it doesn't expire when they close the browser) If they don't allow cookies, it get's a bit trickier but still doable.

You can then append an identifier you composed yourself and stored in the db, to each link (like PHP does for non-cookiers).
When they request a new page, the global.asa's session.on_start sub is called and you can there check if they have a valid value for the identifyer in the querystring.
(for instance the identifier could be 15784530 --> 1 + 5 + 7 + 8 + 4 + 5 = 30 so i's valid according to your algoritme)
If they have a valid link, don't add a record to the session-table, but update the one with 15784530 in the identifier column. Or check if that records last-request time is within your timeoutlimit. (you'll have two timout setting. On ion your app, based on the timestamp of the last request in your sessiontable, and the ASP tiout, which should be higher)
If it's an invalid identifier, you deny access.

I fear this makes it even more confusing.

[BigDaddy]

My, that seems like a lot of work to track user activity.

I will say though, that I have kicked around the idea that it would be nice to have some data on what gets used in my site. My boss has considered buying WebTrends, or whatever the name is, to track the stuff.

[fractalvibes]

I would get on the phone with this user for however long it takes...most likely they are closing their browser down or doing something totally stupid. Especially users used to old-style mainframe terminals and systems have difficulty adapting to current technology...and make stupid requests - I want this list of names to appear alphabetically, but Roger Smith's name needs to appear first......mentality...