views:

81

answers:

5

Using C# Visual Studio 2008 and SQL Server 2005.

  • One database server.

  • One webserver

  • Three clients

  • Webpage name is alpha. Site name is mysite.

I want that only one client at a time can view the page alpha. If one is viewing the page and another from another computer tries to view the same page, access is denied.

Is there any way to configure IIS so limit computers connecting to a particular page?

Is it possible to achieve this by using a static class so that only one instance of this class is made and when another tries to make ERROR?

How to achieve this?

Please note, there are many pages. I only want to restrict people' views on this page.

+3  A: 

There are no built in limits the way you describe, and I am not sure what a static class is supposed to help with.

I would use an application variable, storing the IP address of the first client and some sort of timeout and set/check this on the page you want to protect in this manner.

Oded
There are several fun problems with this idea (while it's pretty much the only option.) Assuming you are only counting the IP address then a proxy server/NAT could get you around this block. If you rely on some cookie/session token and a timeout you could denial-of-service yourself if you close the browse window without ending the session (until the timeout expires) These are not meant as negatives to this answer but as to warning of the requested solution.
Matthew Whited
+4  A: 

As you will not be able to distinguish a refresh of the page from the same browser opening another tab, I don't see any way to make such a scheme work.

Why do you need this? Perhaps there are other alternatives that are better?

Oded
+2  A: 

The short answer is: I don't think you can do this.

The not so short answer is: You could check from which computer/IP address a request originates by checking Request.UserHostAddress, temporarily store this IP address "somewhere" and prevent displaying the page to the same IP address again. But there are some problems with such an approach:

  • you will have to clear the list of "active" client IP addresses sometime
  • you will not be able to distinguish different users/computers if they are behind a firewall/proxy/etc (they will all show the same IP address to your web app)
M4N
+1  A: 

I suppose theoretically it is possible.

You could do this with authentication + cookies + javascript.

Use authentication to get the users logged in and maintain status per user of what page has been served. Set a cookie in that browser to allow not having to log in again.

Now you can probably use the onUnLoad event (or whatever or AJAX as a keep-alive + erase DOM on timeout etc) in javascript to clear (or maintain) the status of a particular page for that user.

Whenever user requests a page, check whether he is logged in and has that page open. If the status says he has it open, you can deny a concurrent view. If he uses a different browser, you can ask for logging in again, because of missing a cookie etc.

Of course, other constraints might prevent you from using this.

Disclaimer: I haven't tried it myself and there could be ways to get around this.

Moron
While this approach *may* work within a single browser, it would not restrict concurrent access in separate browsers, since each has its own cookie store and, since they're in separate processes, they have completely separate javascript environments which cannot interact with each other.
Dave Sherohman
@Dave: If user uses a different browser, you need to ask the user to log in again. You already know he is logged in using a different browser/computer. I don't see why that won't work. There is no assumption about interaction of different javascript environments here. In fact this approach could even be made to work across different computers! The status data is in the server, not the client.
Moron
A: 

An inefficient way to do this could be to put each user's ip and current page into a database and then query against it for all subsequent requests by that ip. Add an onUnload event to each page that deletes the unloaded page from the database.

John