David,
I'm just getting to know servlets in depth, and have recently
read (and reread a few times) the servlet spec.
Two sections of the spec (2.3) are relevant (I think Orion is
at 2.3?):
> 3.1 Scope of a ServletContext
>
> There is one instance of the ServletContext interface associated
> with each web application deployed into a container. In cases
> where the container is distributed over many virtual machines,
> there is one instance per web application per VM. Servlets that
> exist in a container that were not deployed as part of a web
> application are implicitly part of a "default" web application and
> are contained by a default ServletContext. In a distributed
> container, the default ServletContext is non-distributable and
> must only exist on one VM.
So, if you've got a distributed application, then you can't store
it in the servlet context. More specifically:
> 3.3.1 Context Attributes in a Distributed Container
>
> Context attributes exist locally to the VM in which they were
> created and placed. This prevents the ServletContext from being
> used as a distributed shared memory store. If information needs to
> be shared between servlets running in a distributed environment,
> that information should be placed into a session (See Chapter 8,
> "Sessions"), a database or set in an Enterprise JavaBean.
I know you didn't say that you had a distributed environment, but
you don't want the info stored at the rooted "web application"
level either.
If you're not in a J2EE environment, it looks like some external
resource is your only option.
A simplistic way of accomplishing this would be to:
Create a table w/ a single column (and primary key) of userid.
On login attempt, insert the userid into the table, if you get
a key error, then don't log the user in and inform them that
the login is already in use.
(Note that AOL Instant Messenger just logs out whoever had been
logged in and hands the session over to the new client-
-personally I like this for various reasons. Say, I've left
myself logged in at work and am allowed to log in at home. If
I were ever suddenly logged out, I'd log back in and change my
password as quickly as possible. Not perfect, but good enough
for the largest ISP.)
On logout, delete the userid row from the table.
If you're in a J2EE environment, then implement identical
functionality in an EJB.
I'm sure there are more complicated strategies available, but
this is a good starting point.
--jim
David Morton wrote:
>
> I am building a system that protects content by username and password. No
> problem there. The more complicated part of the system prevents two people
> using the same username and password at the same time on our web site. I
> have a plan to do this, but I haven't seen if there are any common
> methods/techniques/strategies/design patterns to do this in a jsp
> environment. Nor do any of our developers have any experience in doing this.
> Currently, I am just going to store server generated sessionId's and
> userId's with other necessary data/time checks......of course the user must
> be able to take over use of that username and password because the browser
> may crash...or they forget to hit logout....and also I must flag when this
> happens too many times in a period of time as a red flag....obviously with
> an html web site, there is no 100% accurate way to only have one user using
> the site at once, however, I can build it well enough that 95% of the users
> that are giving out their passwords won't because it is annoying to keep
> re-logging in and being locked out for an hour if you trip one of our red
> flags.....thoughts? experiences?
> This is not for a porn site, however, I bet that porn people have
> something like this.
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
