>> 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.
I don't like catching an exception much either, but I think the isSecurityManagerAvailable() method might cause us problems - SecurityUtils is a very public-facing API and having that method might confuse people - in most cases, a SecurityManager should always be available. That one wouldn't be available is a client-tier-only very special case. Maybe catching the exception for now is ok until after 1.0? Maybe we can deal with it a little cleaner after the release? > 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. I think the build process signed the .jars but wasn't run as part of the normal development build cycle. I think we called a specific ant target at the time. (kind of like using a Maven profile). > 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. I agree - it'd be nice to move anything that might delay the 1.0 release that isn't critical or a bug to be dealt with afterwards. Also, if we change the JNLP file from using properties to using arguments (<argument>...), we won't need to sign the .jars at all. That should be ok. > 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. I'd be happy maintaining this, but when we made the switch to Maven, it was never high priority for me to figure out to make it play nice w/ the Maven build. Now that you have helped out with this (thanks!), I'm happy with maintaining the code again if no one else wants to. I might have some reasons in the coming months for showing this work in various client environments ;) Another idea is, once we become a top-level project is to maybe move all of the samples to a samples/recipes project? Kind of like Wicket's wicket-stuff project or similar? Cheers, Les
