Session time-out due to inactivity.

[x56h34]

I appologize if this question has been covered before. I tried to use the search function, however the results were unrelated to my question. :-(

I was wondering if session time-out could be increased to something like 1hr of inactivity, before the system automatically logs a user out.

I mostly do my Amiga.org browsing from work, and when I become too busy to post or refresh my session, I would minimize the IE browser window (with Amiga.org page loaded in it), and usually get logged out by the system due to inactivity. I think that this time limit should be set for 1hr. Right now, it feels like...30 minutes before time-out?

What does everyone else think about this?

This is by no means a must, but a mere suggestion. I can certainly live with present rules and conditions. :-)

[Argo]

Have you ever checked "Store my username in a cookie for 1yr" in Edite Profile?
I've never had to login, except for the inital login. I just start my browser every day and when I go to Amiga.org, I'm logged in. It's the same for AW and other sites I have to log in to.

[x56h34]

I don't have it checked. It is now though. :-)
Thanks for the suggestion.

[Floid]

As a suggestion for 'fixing all this,' not that it's easy...

The main annoyance is, of course, that if you time out, the screed you spent a decade writing disappears.  Moz/Firefox will *usually* let you recover it if you go 'back' after logging in -- that's actually my habit, sign on in a separate tab so I can take the one step back and whack 'submit.'  You can get into a 'perfect storm' as I did with a previous article, where I filled my disk so Moz couldn't cache it (Why can't *it* use memory?  Well, actually, Epiphany goes nuts in exciting and different ways than regular Moz when it can't write the cache map, and viewing the emoticon popup blew the form out of the memory cache, it seems)...

Not all of us feel like cookie-ing or are in appropriate situations to (though I am so I oughta suck it up), but seems like the 'appropriate behavior' would be a fixed buffer on the server-side that would accept a submission no matter what, starting the expiry timer ticking when it receives it (along with Javascript magic on the form to warn you if you're approaching the size of it or something), giving you a chance to authenticate your right to commit it without explicitly 'throwing it out' the moment you whack submit.

There's a resource-exhaustion DoS risk in that, but there's a resource-exhaustion DoS risk in running an internet-facing webserver, and the timeout for caching the 'un-pre-authorized' submission could be relatively small (if the user doesn't go "Oh, crap!" and sign in within 5 minutes, it's pretty obviously junk) ... while I assume A.org in particular normally accepts <2MB/5 minutes of forum text, so the 'expense' of implementing it with a cap would be small (and not fail on users unless the feature actually comes under attack)...

...while, of course, I'm a pedant, and can't imagine wiring up the behavior myself.  :-D

[Argo]

Um, sure if you want to rewrite that part of xoops.
  Okay, so have a holding tank datebase table for these session time out anon posts. They would be put into the holding tank DB table tagged with your IP to associate it. Though that brings its problems, though if you login again during the same network connection session your IP shouldn't change. Unless it's like AOL and then you have rotating IP on every network connection. Then it would be impossible to associate the post with the correct account.
The problem is, with not being logged in, the only identifier for a post is the writer's IP address. Cross checking with the last x logged out/session timeout user's IPs. Unfortinatly, I don't know that Xoops stores such data.
One of the problems with what you suggest, is it opens up posting to people who would spoof their IP address, thus end up posting as someone else. Depending on how common this posting situation is, it could cause the use of significant server resources.
It would be like trying to authenticate a letter with only knowing the sending address, not knowing who sent it, and not being able to go to the address to ask who sent it.

[Floid]

Holding tank, yes.  This would require the forum hand you something unique (the post_id in the URL?)

The idea is to start the "discard this submission" timer running when the submission comes in, not before the user can know they've done something wrong.

I'm missing something about how this would allow spoofing, because the l/p would still be required to *commit* the post to the database, the forum ("web app") would just take over caching data you just handed it because the browser can't always be trusted to (especially early-model IE, poof, it's gone).  If the user can't provide the l/p pair to "save" it from the holding tank, it expires rapidly -- but is never lost 'even before' the user pushed the submit button, which is the minor annoyance right now.

Maybe I'm slacking, but I fail to see why IP really enters into it... you can't expect a unique association there, all the thing has to do is buffer *any* post thrown at it, and cycle off the FIFO or whatever if it gets flooded.  Whatever I said above, the token would come in after -- "Hi, welcome to the A.org save-your-butt-system.  I've forgotten about whatever session you claim to be coming from, but recorded your submission as temporary entry 12345678, here is a preview spat back at you so you can cut-and-paste at your leisure, please enter a l/p within 5 minutes from current time X:XX UTC."**  If the user's fast enough, they submit a form associating 12345678 in the "holding tank" with "Floid / Floid's Password" (re-entered, since nobody was logged in), and if not, *poomf,* it's gone.  Maybe if an 'attacker' guessed an ephemeral ID he could purposely/accidentally ascribe an abandoned submission to himself, but that's weak; the only other thing that can be done is to 'clog the buffer,' which would only affect those users not-logged-in anyway.  :-)

It's like holding envelope #uuid while the guy (authenticated as owner of #uuid because he's standing in front of you and hasn't moved when you hand that key back to him) scribbles his name on it to be mailed.  Rather than having him walk up to the counter, hand over the envelope, and "Oops, you were standing in line for more than 15 minutes.  *ZZZRIP!* through the shredder!"

(And heck if I know, but it probably would require mangling Xoops.  See DSLReports for a chunk of forumware that does it, though... I think they also leave your username floating around somewhere in the form to be submitted back -- what with having to have been logged in first to try to post -- so the system remembers who you're "trying" to be and only has to prompt for the password.)

**I'm an idiot.  The preview is the key; by returning what you just submitted, it never has to expire, since you just have to submit valid ID (l/p) with the text to have it processed, and putting it all on one page means you can do it with one 'resubmit'/'post' button... like how DSLReports does it.  Of course, the system would still have to be smart enough to be able to plonk it onto the end of the thread, handle the thread-no-longer-exists case, etc...

[Floid]

Oh, now I see what you meant about the IPs... but if you just *pong* it back to the not-logged-in-IP that sent it a millisecond ago and demand they "file the application again with the proper credentials," that sidesteps the whole issue, right?

Edit:  I think the sane way to phrase this would be something like "take an exception in the form handler to return the darn filled-in form with a request for authentication" -- and forget all about it, but the session-initiation code then needs to watch for incoming BB posts along with the login transaction, or something like that...