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

  • Thread starter Thread starter Robbe Morris - [MVP] C#
  • Start date Start date
R

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.
 
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 said:
tried to write an ASP.NET 2.0 site that could restrict the number of
active sessions before disabling the application.
Click to expand...

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...
Click to expand...
 
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
Click to expand...

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)
Click to expand...

That solution has come up quite frequently in here, but is very unreliable
for fairly obvious reasons...
 
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/tutorial...af-5cd3abe27a75/net-propertygrid-control.aspx
 
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.
Click to expand...

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...
 
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/tutorial...af-5cd3abe27a75/net-propertygrid-control.aspx
 
Well if application is precompiled and the name for that Application
variable not obvious, like Session_count then it might work

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


George.
 
Back
Top