On Fri, Apr 2, 2010 at 10:09 AM, Les Hazlewood <[email protected]> wrote: > 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.
Yes, I know of the prefix. The Shiro code is not a problem anymore, but it looked like it was some underlying code that was trying to read the http.proxyHost or some such property (but a property that isn't specifically sanctioned for sandbox mode) so I don't know if there's an easy way to stop it from doing that. > 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? Right, you can only launch the webstart app if you are logged in. But the webstart app doesn't share the same session, or specifically, doesn't carry the same session cookie in the http remote invocation headers as the user's browser, so the request never reaches the remoting servlet. Either there was some additional mechanism to deal with that but it was lost along the way or I just don't understand how this configuration could work. The SecureRemoteInvocationExecutor itself does the expected thing, creating the subject from the session id argument if the request is allowed to progress that far. Kalle > 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 >> >
