Actually there is a neat little trick about the system properties for JNLP apps: if you prefix the property with 'jnlp.' or 'javaws.', you can read the property without a security check. So something like 'jnlp.shiro.session.id' should work fine and then we'll save ourselves the jar signing time.
I'll take a peek at the authentication issue. The idea was that you would authenticate via the webapp first (JSP) and then launch the webstart app. So, the /remoting/** = authc, ... line was added as an example of a secure app that can only be used if already authenticated. Does this make sense? Les On Thu, Apr 1, 2010 at 5:01 PM, Kalle Korhonen <[email protected]> wrote: > On Fri, Mar 19, 2010 at 3:47 PM, Kalle Korhonen > <[email protected]> wrote: >> On Fri, Mar 19, 2010 at 3:19 PM, Les Hazlewood <[email protected]> wrote: >>>> Well, actually the problem is not the jnlp file but >>>> SecureRemoteInvocationFactory itself as it tries to do >>>> System.getProperty(SESSION_ID_SYSTEM_PROPERTY_NAME) - are you >>> A probably sufficient solution would be to set a static property in >>> WebStartDriver's main method before instantiating the >>> ApplicationContext. Then you can reference that property from within >>> the Spring xml when defining the SecureRemoteInvocationFactory bean. >> Yeah, that's nice and simple - I'll get it implemented thanks! In >> fact, it would almost obsolete catching the exception, since it should >> likely prefer a session id that is explicitly set. Almost, not >> completely though - the code still would reach the part the gets it >> from the sessionid if the previous exception is caught and ignored. > > Ok, that was nice and simple but the underlying http transport code is > trying to read some other system property, so there's no easy way to > avoid signing the jars. However, I changed the implementation anyway > to use the argument and to inject the session id > SecureRemoveInvocationFactory as a constructor argument. I don't > really like the whole sessionid heuristic code but will do for now and > can be changed later without touching the interfaces. This is > committed. However, and I hate to dump this thing on you Les, but the > remaining issue is authenticating that http remote invocation call. > Currently it fails and redirects to the login page which obviously > throws an exception when remoting. So, the part I'm missing is how and > where is the authentication handled for the remoting requests. > > If you take out this line: > /remoting/** = authc, perms[remote:invoke] > from samples-spring/src/main/webapp/WEB-INF/applicationContext.xml, > starting the webstart app will succeed and generally works. Note that > if you run it in-place, you need use mvn jetty:run-exploded rather > than mvn jetty:run (because the build preps the target, rather than > the src directory with the webstart app). > > Kalle >
