shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: svn commit: r911722 - in /incubator/shiro/trunk/samples/spring-client: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/shiro/ src/main/java/org/apache/shiro/samples/ src/main/java/org/apache/
Date Mon, 10 May 2010 19:41:28 GMT
>> 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.

Ah, I see now. I think having /remoting/** = authc doesn't make sense
then.  I think it probably makes more sense that a client should be
able to execute a remote invocation at any point in the Subject's
interaction with the system and rely on things like annotations or
code checks to assert a user must be authenticated for a certain

Then, if any filter would be applied to /remoting/** it would probably
more likely be something like an SSL filter or IP filter to ensure the
request is either secure, or comes from a certain IP or IP range or
something like that.

What do you think?

- Les

View raw message