Interrupting navigation.

[Noozer]

I've seen this on a few sites and was wondering if it was a simple task to
implement. I do realize that much would depend on the coding of the various
sites, but I'm looking for a general idea.

User opens a page. A session starts and they are asked to log in. They spend
30 minutes reading the page, then clicks a link. Since they were on the page
for 20+ minutes their session ended. At that point they are asked to log in,
and then taken to their chosen page as if never interrupted.

 

[Spartanicus]

User opens a page. A session starts and they are asked to log in. They spend
30 minutes reading the page, then clicks a link. Since they were on the page
for 20+ minutes their session ended. At that point they are asked to log in,
and then taken to their chosen page as if never interrupted.

Do you have a valid reason to require users to login?

 

[Noozer]

Do you have a valid reason to require users to login?

Well.. Right now it's just a curiousity as several of our intranet sites do
it and others don't. It would be nice if more of these applications would
let us continue if we ended up sidetracked on something else, but trying to
justify the changes to management is usually the killer here.

I'm also learning PHP and do some ASP coding and it would be handy to know.

 

[Spartanicus]

Well.. Right now it's just a curiousity as several of our intranet sites do
it and others don't.

So that's a no then, to satisfy your curiosity: don't require users to
login unless absolutely necessary, problem solved.

 

[Jonathan N. Little]

Well.. Right now it's just a curiousity as several of our intranet sites do
it and others don't. It would be nice if more of these applications would
let us continue if we ended up sidetracked on something else, but trying to
justify the changes to management is usually the killer here.

I'm also learning PHP and do some ASP coding and it would be handy to know.

To answer your question, you need to change the session lifetime so it
does not expire before your user finishes reading a page. Here is the
section you need to reference:

http://www.php.net/manual/en/ref.session.php
PHP: Session Handling Functions - Manual

 

[Jose]

To answer your question, you need to change the session lifetime so it does not expire before your user finishes reading a page.

However, presumably if he's using sessions to begin with, the purpose is
to expire a session in case the user just wandered off without logging
off. There may be no magic number. (i.e. most users who abandon without
logging off do so after five minutes, but those who stay will stay for
twenty while reading stuff). If leaving an abandoned session open is
sufficiently risky, then the original question remains.

Jose

 

[Toby Inkster]

User opens a page. A session starts and they are asked to log in. They spend
30 minutes reading the page, then clicks a link. Since they were on the page
for 20+ minutes their session ended. At that point they are asked to log in,
and then taken to their chosen page as if never interrupted.

Reasonably easy, yes. This example is in PHP, but the same idea should
work for other languages. At the top of every page that requires
authorisation:

require_once "checkauth.php";

In checkauth.php, do this:

<?php
function check_is_logged_in ()
{
// Write this function yourself.
// Return TRUE if logged in.
// FALSE otherwise.
}

if (!check_is_logged_in())
{
$me = $_SERVER['REQUEST_URI'];
$script = "http://{$_SERVER['HTTP_HOST']}/login.php";
$url = "{$script}?referer=".urlencode($me);
header("HTTP/1.1 303 See Other");
header("Location: {$url}");
}
?>

In login.php, do this:

<?php
$error_msg = '';
$u = stripslashes($_POST['username']);
$p = stripslashes($_POST['password']);
$r = stripslashes($_POST['referer']);

function check_pass ($username, $password)
{
// Write this function yourself.
// Return TRUE if password is ok.
// FALSE otherwise.
}

if (isset($u))
{
if (check_pass($u, $p))
{
$url = "http://{$_SERVER['HTTP_HOST']}/{$r}";
header("HTTP/1.1 303 See Other");
header("Location: {$url}");
exit();
}

else
$error_msg = '<p>Password wrong.</p>';
}
?>
<!-- Embelish this login page yourself. -->
<?= $error_msg ?>
<form action="<?=$_SERVER['PHP_SELF']?>" method="post">
<table>
<tr>
<th scope="row">Username:</th>
<td><input name="username"></td>
</tr>
<tr>
<th scope="row">Password:</th>
<td><input name="password" type="password"></td>
</tr>
<tr>
<td>&nbsp;</td>
<td>
<input type="submit">
<input type="hidden" name="referer"
value="<?=htmlspecialchars($r)?>">
</td>
</tr>
</table>
</form>

 

[Jonathan N. Little]

However, presumably if he's using sessions to begin with, the purpose is
to expire a session in case the user just wandered off without logging
off. There may be no magic number. (i.e. most users who abandon without
logging off do so after five minutes, but those who stay will stay for
twenty while reading stuff). If leaving an abandoned session open is
sufficiently risky, then the original question remains.

That is true. There is no magic value for session expiration, I would
assume if the default is not working for him that he would have to
evaluate the risk/benefit of adjusting the time and security,
sensitivity and nature of how the data is used should be factors.

 

[Alan J. Flavell]

This doesn't really make sense. There's no logical reason - until you
artificially invent a reason - why a reader shouldn't start reading a
page before going to bed, and continue reading it after a good night's
sleep. Equally, they might quit the browser after 30 seconds with no
intention of ever returning. In either case there's no reason that
the server needs to get to hear about it. There simply is NO correct
value to use for a session timeout. Every choice is a compromise,
which is going to be wrong at least as often as it's right, IMNSHO.

However, presumably if he's using sessions to begin with, the
purpose is to expire a session in case the user just wandered off
without logging off.

The questioner would need to ask themselves what is the purpose of
this. If they're trying to protect themselves from the user wandering
off and letting some unauthorised person perform actions in their
name, there isn't a great deal they can do, short of demanding
credentials *at the point of carrying out the action*, rather than
relying on some established session credentials. And even that will
be subverted if the user has taken the option to have their browser
remember their credentials for next time.

Usually the question is "who has the most to lose?". If the user has
more to lose, then maybe you should be advising the user on ways to
protect themself (e.g lock their keyboard when going for coffee,
whatever), rather than trying to be over-protective on their behalf.

But if the user has nothing to lose by casually letting intruders
perform actions in their name, it's logical for you to look for ways
of protecting /yourself/ against such misuses.

There may be no magic number. (i.e. most users who abandon without
logging off do so after five minutes, but those who stay will stay
for twenty while reading stuff).

Indeed. And - just to take one practical example - when I'm trying to
plan a trip with some journey planner, I might need to have
discussions in the middle - checking with a colleague to see if the
arrangements are OK, or checking up with the organisers if an extra
day's stay seems necessary; it's simply *maddening* to be told, when
trying to resume the planner, that the session has timed out and
please to start again from Square One.

If leaving an abandoned session open is sufficiently risky, then the
original question remains.

Quite. But as I say, "risky" to whom? That may be a clue towards
optimising a solution.

IMHO this isn't just about getting a piece of code from somewhere and
applying it. There are countless more-or-less-satisfactory pieces of
session manglement code floating around, that purport to do something
not entirely unlike what one is trying to achieve; but until you're
clear in more fundamental terms what it is that you need, it's hard to
really evaluate them. You risk just annoying your users, to no good
purpose.

 

[Toby Inkster]

function check_pass ($username, $password)
{
// Write this function yourself.
// Return TRUE if password is ok.
// FALSE otherwise.
}

PS: this function should also do something like set a cookie to indicate
whether your user is logged in or not!

 

[Hywel Jenkins]

So that's a no then, to satisfy your curiosity: don't require users to
login unless absolutely necessary, problem solved.

Bollocks. Why don't you just try to answer the guy's question instead
of pumping out your bullshit opinion?

 

[Neredbojias]

With neither quill nor qualm, Alan J. Flavell quothed:

Indeed. And - just to take one practical example - when I'm trying to
plan a trip with some journey planner, I might need to have
discussions in the middle - checking with a colleague to see if the
arrangements are OK, or checking up with the organisers if an extra
day's stay seems necessary; it's simply *maddening* to be told, when
trying to resume the planner, that the session has timed out and
please to start again from Square One.

Yep - maddening and counter-productive. The only site I've ever
returned to after such an occurrence is a bank.

 

[Jose]

it's simply *maddening* to be told, when

trying to resume the planner, that the session has timed out and
please to start again from Square One.

Yes, which I think is why he's asking how to ask the user for a
password, and then start him again from Square Seventeen (or wherever he
was).

Jose

 

[Noozer]

PS: this function should also do something like set a cookie to indicate
whether your user is logged in or not!

Doh! : )

Thanks muchly! It's appreciated!