Re: Removing SBs when expiring HttpSessions ... the challenge continues.
Gerald, Thank you for your explanation. But my question was a little bit different. I was wondering why to take care of removing SBs when there is remote garbage collector which is responsible for it. But maybe you want to make some special cleanning up or you are facing another type of problems I am not aware of. You wrote (snipped): ... to remove session beans that would otherwise stay active and eventually consume all resources and cause the server to crash. My original question was: Why do you think that session beans would stay active after expiring HttpSession? Don't you trust remote garbage collector which I hope is responsible for cleanning invalid session beans instances? Regards Petr - Original Message - From: Gerald Gutierrez [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, March 23, 2001 8:07 PM Subject: RE: Removing SBs when expiring HttpSessions ... the challenge continues. As with anything, the devil is in the details. SBs expire in one of a number of ways. The two main ways are: you call remove() or they time out. This is well known. So if you have your SB bound to an HttpSession, everything works and you get get your SB from the session at any time. The REAL ISSUE is, however, the security issues with how you clean up that SB when the HttpSession expires. This is something it seems no one really understands, and it seems to me to be a fairly critical to the proper working of J2EE. The servlet spec does not say anything about WHO calls HttpSessionBindingListener.valueUnbound() when an HttpSession expires. Assume (arbitrarly) that it is an "unauthenticated user" (Orion calls this a "guest"), then if you call ejb.remove() within valueUnbound(), the EJB will be called with the guest user. Well, what if the remove() method is protected by security constraints and guest is not allowed? What if you had to call other methods to clean up that session? Well, someone said "log in with a special user before calling remove()". It doesn't work because one tries to JNDI-lookup a RoleManager to log in, Orion throws an exception saying "javax.naming.NamingException: Not in an application scope". Okay, so just call remove() and do the login in there. That DID work, but WHY? I have my remove() method secured so only authenticated users can hit it. And what if you had to call OTHER methods in addition to remove()? From the responses, it seems either that no one has previously recognized this as a problem, or that they're ignoring it, or I'm just all wrong. So please, am I wrong, or is there an issue here? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Petr Podsednik Sent: Friday, March 23, 2001 12:37 AM To: Orion-Interest Subject: Re: Removing SBs when expiring HttpSessions ... the challenge continues. Hi, If It is possible I have a question regarding this problem. Until now I was thinking there is no problem regarding HttpSession expiring because of garbage collector which knows what remote references became invalid. Please tell me, if I am wrong and why. If it is must be handled in code what about for example Swing clients machine's crashing? Regards Petr When an HttpSession expires, it calls valueUnbound() on all session-bound variables that implement the HttpSessionBindingListener interface. So this provides a way for expiring HTTP sessions to remove session beans that would otherwise stay active and eventually consume all resources and cause the server to crash.
RE: Removing SBs when expiring HttpSessions ... the challenge continues.
As with anything, the devil is in the details. SBs expire in one of a number of ways. The two main ways are: you call remove() or they time out. This is well known. So if you have your SB bound to an HttpSession, everything works and you get get your SB from the session at any time. The REAL ISSUE is, however, the security issues with how you clean up that SB when the HttpSession expires. This is something it seems no one really understands, and it seems to me to be a fairly critical to the proper working of J2EE. The servlet spec does not say anything about WHO calls HttpSessionBindingListener.valueUnbound() when an HttpSession expires. Assume (arbitrarly) that it is an "unauthenticated user" (Orion calls this a "guest"), then if you call ejb.remove() within valueUnbound(), the EJB will be called with the guest user. Well, what if the remove() method is protected by security constraints and guest is not allowed? What if you had to call other methods to clean up that session? Well, someone said "log in with a special user before calling remove()". It doesn't work because one tries to JNDI-lookup a RoleManager to log in, Orion throws an exception saying "javax.naming.NamingException: Not in an application scope". Okay, so just call remove() and do the login in there. That DID work, but WHY? I have my remove() method secured so only authenticated users can hit it. And what if you had to call OTHER methods in addition to remove()? From the responses, it seems either that no one has previously recognized this as a problem, or that they're ignoring it, or I'm just all wrong. So please, am I wrong, or is there an issue here? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Petr Podsednik Sent: Friday, March 23, 2001 12:37 AM To: Orion-Interest Subject: Re: Removing SBs when expiring HttpSessions ... the challenge continues. Hi, If It is possible I have a question regarding this problem. Until now I was thinking there is no problem regarding HttpSession expiring because of garbage collector which knows what remote references became invalid. Please tell me, if I am wrong and why. If it is must be handled in code what about for example Swing clients machine's crashing? Regards Petr When an HttpSession expires, it calls valueUnbound() on all session-bound variables that implement the HttpSessionBindingListener interface. So this provides a way for expiring HTTP sessions to remove session beans that would otherwise stay active and eventually consume all resources and cause the server to crash.
RE: Removing SBs when expiring HttpSessions ... the challenge continues.
We do not have the problem that you describe. Why? Because we do not let the container perform the authentication. We handle authentication *entirely* in our own code, and completely ignore the J2EE/container authentication. Thus, our servlets always access the EJB SB's using a single user/password that is assigned to the servlet. The user/password are not known outside of the company. As I indicated in my previous posting, we handle everything in the SB's with our own UserSession entity bean. When a user logs in, they get a UserSession EB that determines their priveleges. The privelege is handled entirely within our code. We do not use container privelege at all except to secure the handful of methods involved in establishing the UserSession. This design has eliminated almost every complaint that people have posted regarding container authentication, priveleges, and sessions. Further, it allows us to implement "higher level" permission management that can not be managed by the container (such as, can this user modify a record based on their relationship to the owner of the record). tim. As with anything, the devil is in the details. SBs expire in one of a number of ways. The two main ways are: you call remove() or they time out. This is well known. So if you have your SB bound to an HttpSession, everything works and you get get your SB from the session at any time. The REAL ISSUE is, however, the security issues with how you clean up that SB when the HttpSession expires. This is something it seems no one really understands, and it seems to me to be a fairly critical to the proper working of J2EE. The servlet spec does not say anything about WHO calls HttpSessionBindingListener.valueUnbound() when an HttpSession expires. Assume (arbitrarly) that it is an "unauthenticated user" (Orion calls this a "guest"), then if you call ejb.remove() within valueUnbound(), the EJB will be called with the guest user. Well, what if the remove() method is protected by security constraints and guest is not allowed? What if you had to call other methods to clean up that session? Well, someone said "log in with a special user before calling remove()". It doesn't work because one tries to JNDI-lookup a RoleManager to log in, Orion throws an exception saying "javax.naming.NamingException: Not in an application scope". Okay, so just call remove() and do the login in there. That DID work, but WHY? I have my remove() method secured so only authenticated users can hit it. And what if you had to call OTHER methods in addition to remove()? From the responses, it seems either that no one has previously recognized this as a problem, or that they're ignoring it, or I'm just all wrong. So please, am I wrong, or is there an issue here? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Petr Podsednik Sent: Friday, March 23, 2001 12:37 AM To: Orion-Interest Subject: Re: Removing SBs when expiring HttpSessions ... the challenge continues. Hi, If It is possible I have a question regarding this problem. Until now I was thinking there is no problem regarding HttpSession expiring because of garbage collector which knows what remote references became invalid. Please tell me, if I am wrong and why. If it is must be handled in code what about for example Swing clients machine's crashing? Regards Petr When an HttpSession expires, it calls valueUnbound() on all session-bound variables that implement the HttpSessionBindingListener interface. So this provides a way for expiring HTTP sessions to remove session beans that would otherwise stay active and eventually consume all resources and cause the server to crash.
RE: Removing SBs when expiring HttpSessions ... the challenge continues.
Just a tought: impersonate a role within the SB's method remove instead of
reliying on interactive login:
public void remove() {
//get UserManager
UserManager um = ic.lookup("java:comp/UserManager");
um.login("mySecuritySafeUser","thePassWd");
this.myejbref.remove();
}
I haven't tried this, but I guess it should work, specially if auto-sessions
are on...
HTH,
JP
-Original Message-
From: Gerald Gutierrez [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 3:05 PM
To: Orion-Interest
Subject: Removing SBs when expiring HttpSessions ... the challenge
continues.
When an HttpSession expires, it calls valueUnbound() on all
session-bound
variables that implement the HttpSessionBindingListener
interface. So this
provides a way for expiring HTTP sessions to remove session
beans that would
otherwise stay active and eventually consume all resources
and cause the
server to crash.
The reasonable thing to do is to call ejb.remove() (and whatever other
methods) within the valueUnbound() method so that the SB can
clean up and be
removed on the event.
HOWEVER, if the SB is protected by security constraints,
calling methods on
the SB causes either NullPointerExceptions, or SecurityExceptions.
In my case, I have a HttpSession which has bound an SB, which
in turn has a
reference to an EB. When the session expires, I need to
remove the SB, which
in turn must call a method on the EB. If I attempt to just
call sb.remove(),
the ejbRemove() method is called but a NullPointerException
is thrown in the
EB's wrapper. If I call getCallerPrincipal() in the SB first
(which returns
me the "guest" user), then call the EB, a SecurityException is thrown.
Ignoring the fact that the different exceptions may be an
Orion bug, the
fact still remains that the "guest" user is calling the SB
when calling
through the valueUnbound() method.
SO, the question, once again, is: When an HttpSession
expires, what's the
proper way to cleanup and remove the EJBs that are bound to
that session?
Gerald.
Re: Removing SBs when expiring HttpSessions ... the challenge continues.
Hi, If It is possible I have a question regarding this problem. Until now I was thinking there is no problem regarding HttpSession expiring because of garbage collector which knows what remote references became invalid. Please tell me, if I am wrong and why. If it is must be handled in code what about for example Swing clients machine's crashing? Regards Petr When an HttpSession expires, it calls valueUnbound() on all session-bound variables that implement the HttpSessionBindingListener interface. So this provides a way for expiring HTTP sessions to remove session beans that would otherwise stay active and eventually consume all resources and cause the server to crash.
