OnLoggedIn/OnLoggedOut - not session?

[David Thielen]

Hi;

It seems to me that you log in/out of a session. But it seems that these
events are tied to the Login and LoginStatus controls - is that correct?

 

[Dominick Baier]

??

state management sessions and authentication sessions are two distinct things.

The login controls have such events but this has nothing to do with session.

was that your question?

 

[David Thielen]

I think so. As I understand it a state management session is the Session
object and the authentication session is I am logged in. But isn't the
authentication session just a state of the state management session?

 

[Dominick Baier]

no - as i said - they are two distinct things -

i thought you already bought the book i recommended to you

dominick

 

[Steven Cheng[MSFT]]

Hi Dave,

I agree with Dominick, the SessionState's id/token is a different from the
forms authentication's ticket. Though both of them are stored in client
cookie by default, they're two distinct objects. In other words, there is
no relationship between the two state values. Is there any particular task
you want to accomplish relying on those two values? Here is a web article
descrbing detailed on the ASP.NET forms authentication mechanism:

http://aspnet.4guysfromrolla.com/articles/072005-1.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


==================================================

Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.


Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial

response from the community or a Microsoft Support Engineer within 1
business day is

acceptable. Please note that each follow up response may take approximately
2 business days

as the support professional working with you may need further investigation
to reach the

most efficient resolution. The offering is not appropriate for situations
that require

urgent, real-time or phone-based interactions or complex project analysis
and dump analysis

issues. Issues of this nature are best handled working with a dedicated
Microsoft Support

Engineer by contacting Microsoft Customer Support Services (CSS) at

http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[David Thielen]

i thought you already bought the book i recommended to you

I bought it - do I have to read it too <g>?

Seriously I will sit down with the book tomorrow and work my way through
this. If I hit a question I'll post here. And if I figure it out, I'll post
my solution here.

 

[Steven Cheng[MSFT]]

That's fine. Looking forward to your good news.

Regards,

Steven Cheng
Microsoft MSDN Online Support Lead

 

[David Thielen]

Hi;

Ok, I've re-read chapters 2, 5, & 7. And I understand why session state and
login state MUST be distinct. And I can see how I can use events to see when
a user logs in and out using forms authentication.

What I can't find is:
1) A way to know when a forms authentication ticket expires.
2) A way to track log in/out/expire for windows authentication. (I know they
don't actually login - but I need a way to know they are hitting the system).

Here's what I am trying to do. Our ASP.NET application is licensed per
concurrent user. It can be run using Windows authentication or Forms
authentication.

So for forms authentication I need to know when someone logs in, when they
log out, and when they expire.

For Windows authentication I need to know when they hit the system and when
N minutes have expired since they last hit the system (ie they "expire"). And
I assume there is no "logout" concept for Windows authentication although I
can see it being useful for our case.

Suggestions????

 

[Dominick Baier]

Hi,

1) there is no event or something similar if you are looking for that - you
could write a db record on every request to keep track of last activity time
2) there is no expire for windows accounts. Again you could keep track of
last activity manually

you have to build a manual logic for that and tbh it is just crazy to licence
a web app based per concurrent users...

dominick

 

[Dominick Baier]

well - don't take this personal...

you have to build a manual logic for that and tbh it is just crazy to
licence a web app based per concurrent users...

i just think that this is just not suited for a stateless protocol.

 

[David Thielen]

Hi;

I don't take it personal - it's a good point. Unfortunately customers don't
care that it's not a good approach for a stateless protocol - they vastly
prefer concurrent user licensing to total number of users licensing.

This is going to be a PITA I'm guessing.

thanks for the help - at least I know what I have to do.

thanks - dave

 

[Joe Kaplan \(MVP - ADSI\)]

The real trick is determining what concurrent actually means. It seems like
session state would be a better way to hande that. Session state is the
"thing" that is added to HTTP to make a stateless protocol stateful and
works the same way with forms and windows auth.

Perhaps you just write an HTTP Module to check how many sessions currently
exist when the session is created. If there are too many, then you block
them. You could also include a web widget to clear a user's session state
to make it easier for the customers to get another session.

The problem is that you can only hook the session start and end events with
InProc. I don't see an obvious way to query the "state" of the session
state to find out how many sessions exist. I could be missing something
though. I didn't look very hard.

You could implement your own cookie-based statement management system to
support your licensing.

Joe K.

 

[David Thielen]

good idea - I will try this. I can also query the IPrincipal of the user when
a Session is created and use that too.

thanks - dave