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

  • Thread starter Robbe Morris - [MVP] C#
  • 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.
 
A

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 said:
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...
 
M

Mark Rae [MVP]

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...
 
R

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/tutorial...af-5cd3abe27a75/net-propertygrid-control.aspx
 
M

Mark Rae [MVP]

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...
 
R

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/tutorial...af-5cd3abe27a75/net-propertygrid-control.aspx
 
G

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
 
G

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top