|
WRONG!!!
As I see it... There is nothing in
the post, that says SESSION or HTTP or JSP or SERVLET.
I have stumbled upon this problem
many times. I've raised that question on this list many times.
However... Except for threads like
"Orion deal blah, blah" I hardly see any meaningful mail on this list. Have to
use it however.
The problem comes from other
place.
SITCH:
Step 1: Set up an InitialContext
(url, factory, principal, credentials)
Step 1.1: Do your job (create,
use, remove etc.)
< watch here >
Step 2: TRY to get another
Context with something different as parameters (let's say different user, url,
password, any of these, except for the factory).
<RESULT>
You get an InitialContext, that
points exactly to the same target as the first one. The same target server, the
same target application, the same user, the same password. This is NOT how it
should be.
The only way to get a difefrent
context is to receive an Exception while communicating. Then you can get
different Context.
WHY???
Someone on the list proposed to use
"dedicated.connection=true" in the InitialContext hashtable parameters. Haven't
seen it to work...
Hoping, to put the guns away, and do
some job, isn't that why we are here?
Lachezar.
its
in the "clean things up" step that something went wrong.
You
need to do a session.invalidate(), and then create a new guest session with a
session.create("true"). Here is the bit in the RequestProcessor of the
BluePrint (petstore):
if (event
instanceof LogoutEvent)
{
... whatever
...
session.invalidate();
....whatever
....
HttpSession validSession = req.getSession(true);
...whatever ...
}
This
is usually done in a servlet. I would do the same thing here. Instead of using
the client - > slsb -> whatever ... use client -> servlet -> slsb
-> whatever bean. This way, you can abstract whatever login/logout and
session control directly with the servlet, and you also abstract instancing
the slsb -> whatever bean. The servlet can also be loadbalanced (the slsb
can't be) so if you want failover capability, you get it.
regards,
the
elephantwalker
Hi,
I'm trying to get the security portion of a
project working, in which a java client connects to a stateless session
bean after login. As far as I can tell, Orion doesn't seem to
properly pass around principal objects in stateless session
beans.
This is the sequence that my test client
runs:
1. Prompt user for user ID &
password
2. Create an InitialContext containing the user
ID and password (as "java.naming.security.principal" and
"java.naming.security.credentials", respectively.)
3. Look up the stateless session bean's
home
4. home.create() the stateless session
bean
So far, so good. The stateless session
bean correctly identifies the user ID within its session context's
principal. Now I clean things up and repeat the process:
5. remove() the stateless session
bean
6. close() the InitialContext (just in case...
I even went so far as to remove all of its environment
properties.)
7. Log on again: prompt for a different user ID
& password
8. Create a new initial context as in step
2.
9. Look up the stateless session bean's
home
10. home.create() the stateless session
bean
This is where things go wrong. I get the
principal out of the stateless session bean's session context, which
indicates that I'm logged in as the first user! The problem is that
the bean is never calling "setSessionContext" on the second creation.
If I re-start the client however, it works correctly.
The only way I can think of to get around this
is to use a stateful session bean instead... I don't like that,
because I don't need to maintain state! Has anyone else encountered
this problem? Found a solution?
Thanks,
Mike
| 