(To do it in ASP you'd need to add Application variables, keep refreshing them when pages are accessed, and probably handle starting a connection in the session_start in global.asa, which is equally a pain) An applet would run on the client machine - quite a few chat sites use java applets to facilitate real-time communication, for example. It's not at all like ASP, and would be restricted to clients that have Java enabled, and would require a server program to maintain the connections. That would be more reliable in some ways because the applet be kept running on the client (perhaps in a hidden frame so it's not apparent or reloaded), and the server just needs to monitor how many connections are open, and limit it to whatever number. It's not that practical when you can't assign another IP address or port, and you need to write the client and server applets, however, and wouldn't really be a Zope-based solution, either. Unless you need an absolutely real-time method, rather than ones that can hold a session open for a few minutes extra, use the other method suggested. The best way may be to write a product that increments the values. You may be able to avoid using persistence, too - since you would reset the active connections to zero when the server is rebooted, too, but I haven't tried anything like this in Zope myself so I'm not sure, and any implementation would have to be done by someone else... HTH, David Burton 10/06/2002 09:43:39, John Doe <gvd_76@yahoo.com> wrote:
Hmm, I had an analog idea in mind, but instead using the browserid; ip is probably better (if I add the port to prevent proxies)
This applet: would this simulate the functionality of ASP (where it's apparently possible to keep session information)? Do you have an example of such an applet or further information?
In either case, thx for your insights so far.
Grts, John
--- David Burton <eloquence@eloquent-designs.f2s.com> wrote:
One problem with this idea is that HTTP is stateless.
You would only be able to log the number of concurrent users on the basis of assuming that a session times out after a given period of inactivity (say 5 minutes) or on logout.
(Alternatively a little Java Applet could provide login/logout calls).
In either case, you would probably have scripts that check the last login times for each user (perhaps differentiate each user by IP address, so that multiple users can log in with the same username if necessary?). The calls to the login checking script from each protected page could check if any of the current sessions have timed out, and remove them if they have. Then it could check if the user is already on the list, updating their last access time if they are. Failing that, it can check if the maximum number of users has been reached, adding the user if there is another user allowed, and otherwise redirecting to a 'Max Users Reached' kind of page.
Theoretically this wouldn't be too hard to do - you'd need to make sure that the users have permission to update the object storing these login details (which could be just stored as properties in a DTML Document even, or a database table alternatively), or give the update script the permission to update that object.
That would be one way of doing things... I don't know if there's a pre-written product to do this - I haven't seen one...
HTH, David Burton
07/06/2002 13:08:37, John Doe <gvd_76@yahoo.com> wrote:
Is it possible to restrict the number of concurrent logins per user (maybe using a SessionManager?) ?
__________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
"Into the abyss we stare, hoping that the abyss does not gaze so intently upon us"
__________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
"Into the abyss we stare, hoping that the abyss does not gaze so intently upon us"