>> 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
method.
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