On Mon, Feb 22, 2010 at 6:59 AM, Les Hazlewood <[email protected]> wrote: > On Sat, Feb 20, 2010 at 4:47 AM, Kalle Korhonen > Here is a little back story on how/why the > SecureRemoteInvocationFactory works the way it does: > It primarily existed to support remote client applications that were > started/launched after a server-side session had been created first > (think login HTTPs page --> success --> launch/show app). Then the
Right, that's sort of what I gathered from the source. > My opinion is that we allow a SecurityManager instance to be injected > and we can use that if it exists. If not, we try > SecurityUtils.getSecurityManager (it can be the case in a single-user > standalone application to make a client-side SecurityManager proxy > accessible via a static reference). But if that method throws an > exception (which should be a changed to a type-safe exception, like > UnavailableSecurityManagerException), we just ignore it for the > remoting factory and assume there isn't one. In that case, the Yes, with that change it'll work. Still, I don't really like the idea that you have to catch an exception and then ignore it when you know it doesn't have to be there. Of course, we could add one more operation such SecurityUtils.isSecurityManagerAvailable() but I'm not sure if adding more code is the right way to solve it. What do you think? Regardless, SecureRemoteInvocationFactory needs to handle the case one way or another. So, with that change (still uncommitted but I'm simply catching and ignoring the exception now in my local copy of Shiro support) I can almost get the webstart to work. This might deserve a whole separate thread but if you've been watching recent commits, I've automated the whole sample with Maven. It's turning to be more of an exercise to use Maven rather than a demonstration of secure remoting capabilitites. >From the commit logs, it seems that the sample had been broken for quite some time, possibly for a couple of years. I'm sure previously it simply had the libs manually signed and checked in. Now, the build collects the dependencies, signs them, generates the JNLP file and zips it up ready to consumed by the spring web application. This whole thing comes at a high cost though: [INFO] Apache Shiro :: Samples :: Spring Client .............. SUCCESS [1:38.361s] [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 4 minutes 34 seconds Signing the jars for webstart takes quite a bit of time. Signing is required since SecureRemoteInvocationFactory calls System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) which is not permitted in the unsecured sandbox mode. One option is to move the samples-spring-client to the root level and make it an independently releasable module, but the problem is that somebody still needs to build it or it needs to be used as a released dependency (but that also requires it uses only released dependencies, and there are none available it could use right now). I'd suggest we suffer through until 1.0.0 release, then change it so. A totally different option is to evaluate the need for the whole sample and eliminate it if it's not useful to anybody (I'm big on eliminating stale code :) ). If we are not running and maintaining the sample, it doesn't deserve to exist. I'm not really suggesting removing it - I think it does showcase Shiro's flexibility rather well - but just saying that we need to understand the maintenance costs if we want to keep it around. Kalle
