ASP.NET sites with built-in max session count governors?

[Robbe Morris - [MVP] C#]

For reasons I won't get into here, I'd be curious if anyone has
tried to write an ASP.NET 2.0 site that could restrict the number of active
sessions
before disabling the application. By disable, I mean just stop the site
from functioning properly. Of course, the solution would need to be
"relatively" tamper proof.

I've worked up specs for this but was interested in the opinions
of others and any pitfalls they may have faced that I might not
have considered.

--
Robbe Morris [Microsoft MVP - Visual C#]
..NET PropertyGrid Control - ListBox, ComboBox, and Custom Classes
http://www.eggheadcafe.com/tutorials...d-control.aspx

[Andy Fish]

That's pretty much what I would have proposed - though I have never tried to
do this either.

IMHO there's no need to check the session variable at the top of every page
though - session variables are available in the
Application_PreRequestHandlerExecute handler in global.asax so that would do
just as well

Also you could help mitigate the "user closes window without clicking
logout" problem with some javascript that fires when the window closes (and
maybe even when the user navigates away)

Andy
"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:uJ**************@TK2MSFTNGP05.phx.gbl...

"Robbe Morris - [MVP] C#" <in**@eggheadcafe.comwrote in message
news:e2**************@TK2MSFTNGP04.phx.gbl...

>tried to write an ASP.NET 2.0 site that could restrict the number of
active sessions before disabling the application.

I haven't, but I'd have thought it would be fairly simple in essence...

1) In Application_Start, instantiate an Application variable e.g.

Application["Sessions"] = 0;

2) In Session_Start check the value

if ((int)Application["Sessions"] n)
{
// do something - maybe redirect to another page
Session["OKToProceed"] = false;
}
else
{
Application["Session"] = (int)Application["Session"] + 1;
Session["OKToProceed"] = true;
}

3) In Session_End decrement the value

Application["Session"] = (int)Application["Session"] - 1;
As for pitfalls...

If you're not using inproc session management the Session_End event won't
fire.

There's no way of knowing if someone has left your site unless they click
a "Logout" button or something behind which you call Sesson_Abandon() -
this means that if your limit was 100 sessions and 100 users accessed the
site simultaneously and then closed their browser straightaway, no other
user could get until the 100 sessions had timed out...

You'll need to check for Session["OKToProceed"] on every page, otherwise
users will just get to your warning page and then type default.aspx (or
whatever) into their browser's address bar - create a page base class or
use a MasterPage...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Mark Rae [MVP]]

"Andy Fish" <aj****@blueyonder.co.ukwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

IMHO there's no need to check the session variable at the top of every
page though - session variables are available in the
Application_PreRequestHandlerExecute handler in global.asax so that would
do just as well

True enough...

Also you could help mitigate the "user closes window without clicking
logout" problem with some javascript that fires when the window closes
(and maybe even when the user navigates away)

That solution has come up quite frequently in here, but is very unreliable
for fairly obvious reasons...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Robbe Morris - [MVP] C#]

Thanks guys. Basically, I'll be offering a version of the web site
for testing purposes. But, I don't want that version of the web site
deployed to a server and used. So, the session management need
to deal with expired sessions isn't big. But, the tamper proof part is.
I wouldn't want the capability of a developer deploying assemblies
or script code that could overwrite my counters at runtime.

--
Robbe Morris [Microsoft MVP - Visual C#]
..NET PropertyGrid Control - ListBox, ComboBox, and Custom Classes
http://www.eggheadcafe.com/tutorials...d-control.aspx


"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

"Andy Fish" <aj****@blueyonder.co.ukwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>IMHO there's no need to check the session variable at the top of every
page though - session variables are available in the
Application_PreRequestHandlerExecute handler in global.asax so that would
do just as well

True enough...

>Also you could help mitigate the "user closes window without clicking
logout" problem with some javascript that fires when the window closes
(and maybe even when the user navigates away)

That solution has come up quite frequently in here, but is very unreliable
for fairly obvious reasons...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Mark Rae [MVP]]

"Robbe Morris - [MVP] C#" <in**@eggheadcafe.comwrote in message
news:Ol**************@TK2MSFTNGP02.phx.gbl...

Thanks guys. Basically, I'll be offering a version of the web site
for testing purposes. But, I don't want that version of the web site
deployed to a server and used. So, the session management need
to deal with expired sessions isn't big. But, the tamper proof part is.
I wouldn't want the capability of a developer deploying assemblies
or script code that could overwrite my counters at runtime.

Ah - well the Application / Session method won't help at all, then...

All somebody would need to do is drop a simple page onto your site with
inline server code to get round it by setting your Application variable to
e.g. -10000000

As soon as they typed the address of the page directly into the browser, it
would reset the Application variable...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[George Ter-Saakov]

Well if application is precompiled and the name for that Application
variable not obvious, like Session_count then it might work

George

"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

"Robbe Morris - [MVP] C#" <in**@eggheadcafe.comwrote in message
news:Ol**************@TK2MSFTNGP02.phx.gbl...

>Thanks guys. Basically, I'll be offering a version of the web site
for testing purposes. But, I don't want that version of the web site
deployed to a server and used. So, the session management need
to deal with expired sessions isn't big. But, the tamper proof part is.
I wouldn't want the capability of a developer deploying assemblies
or script code that could overwrite my counters at runtime.

Ah - well the Application / Session method won't help at all, then...

All somebody would need to do is drop a simple page onto your site with
inline server code to get round it by setting your Application variable to
e.g. -10000000

As soon as they typed the address of the page directly into the browser,
it would reset the Application variable...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Robbe Morris - [MVP] C#]

Yep. I figured I'd have to bury checks for operating system and
session counter (not stored in application or session variables) deep
inside some of the assemblies. If the code is obfuscated and perhaps
has some tamper proofing software run on it "should" be ok.

Of course, the OS could be a server platform running on a laptop
or perhaps just a virtual image. But, it would reduce the number
of potential tampers significantly.

Was just curious if anyone else had travelled down this road
before.

--
Robbe Morris [Microsoft MVP - Visual C#]
..NET PropertyGrid Control - ListBox, ComboBox, and Custom Classes
http://www.eggheadcafe.com/tutorials...d-control.aspx


"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

"Robbe Morris - [MVP] C#" <in**@eggheadcafe.comwrote in message
news:Ol**************@TK2MSFTNGP02.phx.gbl...

>Thanks guys. Basically, I'll be offering a version of the web site
for testing purposes. But, I don't want that version of the web site
deployed to a server and used. So, the session management need
to deal with expired sessions isn't big. But, the tamper proof part is.
I wouldn't want the capability of a developer deploying assemblies
or script code that could overwrite my counters at runtime.

Ah - well the Application / Session method won't help at all, then...

All somebody would need to do is drop a simple page onto your site with
inline server code to get round it by setting your Application variable to
e.g. -10000000

As soon as they typed the address of the page directly into the browser,
it would reset the Application variable...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Mark Rae [MVP]]

"George Ter-Saakov" <gt****@cardone.comwrote in message
news:uO**************@TK2MSFTNGP04.phx.gbl...

Well if application is precompiled

Even if it is, a page with inline code would still run, right...?
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[George Ter-Saakov]

It will not. It will give you an exception. "Application has been
precompiled and you can not change it" (something like that).
George.
"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:Ol**************@TK2MSFTNGP05.phx.gbl...

"George Ter-Saakov" <gt****@cardone.comwrote in message
news:uO**************@TK2MSFTNGP04.phx.gbl...

>Well if application is precompiled

Even if it is, a page with inline code would still run, right...?
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Mark Rae [MVP]]

"George Ter-Saakov" <gt****@cardone.comwrote in message
news:Oh**************@TK2MSFTNGP05.phx.gbl...

>>Well if application is precompiled

Even if it is, a page with inline code would still run, right...?

It will not. It will give you an exception. "Application has been
precompiled and you can not change it" (something like that).

OK. Thanks for that...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net