Thanks for correcting my mistake.

So if one then tried to read the user's cookie what would one get?  And
what of the security context surely that will no longer return a UserId
(if one put it there in the first place) ?

Say the user visits the site at 13:00 and navigates away at 13:10 and
the session timeout is set to 20 minutes. Are you saying that for the
last 10 minuters, after the user has navigated away, that the session id
and UserId in the security context will still be there - implying that
the user is still present?  I was under the impression that the session
id relied on cookies (by default). I realise that http is stateless but
is the user cookie cached on the server and not read afresh each time
one "reads" it? - if so, what would happen if one tried to write a
cookie to the now absent user after they had navigated away?

It just doesn't make sense to me that a user navigating away can't be
detected.

You can always have an Admin Account that can unlock a user if she-he
forgets to logout properly.
Also you need to make sure that the processing is done by that user
Can one user start processing then logsout then another user logs in and
Finishes the processing?

The Admin account can unlock or reset flags.

By the way, this is Pain In The A.

On Oct 17, 10:29 am, "Patrice" <http://www.chez.com/scribe/> wrote:

The requirement that only one user be logged on at a time is because
this site is used to process payroll taxes and the processing is done
one step at a time and each step needs to be done in sequence. Like a
state machine.

How do you get the user id? Is this a "Document" or a "Page"
parameter?

Thanks again this has been sooo helpfull.

Steve

You get the userID from the user cookie (where you would've put it) when
the user authenticates [using the _OnAuthenticate() in Global]. If the
cookie ticket fails authentification you get the UserID from your
database when the user logs in. The UserID is then added to the security
context - eg. something like this:

protected void FormsAuthentication_OnAuthenticate(Object sender,
FormsAuthenticationEventArgs e)
{
   blah blah ...

   e.Context.User = new System.Security.Principal.GenericPrincipal(new
FormsIdentity(Ticket2), aRoles);
   Context.Items.Add("UserID", strID);

  blah blah ...
}

So, you can use forms authentification with an encrypted cookie. Whether
or not you use a cookie, the UserID can be kept in the security context
and is then always available to you as: Context.Items["UserID"] (in this
case). There are more sophisticated variants like this with custom
Principals.

Detect the end of a session using this method:
<http://www.eggheadcafe.com/articles/20051228.asp>

»

So why can't you store the current state (against the user ID in some backend
database) at each stage of the process so that multiple people could use
the system at once.

Seems strange to lock people out when you could serve more than one at once...
Is that not better?

--
Rory

There a better way to do this.  In a table, set flags as to what step
has been accomplished, or a "nextstep" value.  Don't let a user into
any page except the one that equates to the "nextstep".

Once that step is being processed, don't allow another user process
it.  Basically whomever clicks "Submit" first wins.