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

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]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Robbe Morris - [MVP] C#" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> 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

"Andy Fish" <(E-Mail Removed)> wrote in message
news:%23$(E-Mail Removed)...

> 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

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]" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> "Andy Fish" <(E-Mail Removed)> wrote in message
> news:%23$(E-Mail Removed)...
>
>> 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#" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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

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]" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> "Robbe Morris - [MVP] C#" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> 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

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]" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> "Robbe Morris - [MVP] C#" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> 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" <gt-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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

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]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "George Ter-Saakov" <gt-(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> 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" <gt-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

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