Hi Scott,
Thank you for the comments.
I suppose this approach is quite specific to our use case. The
actual aspect is:
import
org.eclipse.ecf.provider.remoteservice.generic.RemoteCallImpl;
import org.eclipse.ecf.provider.remoteservice.generic.Request;
import
org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceRegistrationImpl;
public aspect ECFRequestExtAspect {
private ISecurityToken RemoteCallImpl.mSecurityToken;
//serializable parameter to pass (security token in this case)
//advice executed after a new request object has been created
after(Request request) returning :
initialization(Request+.new(..)) && this(request) {
//put the (local) security context in the RemoteCallImpl
instance of the request
request.getCall().mSecurityToken =
SecurityContextHolder.getContext().getToken();
}
//advice executed before the remote service method invocation
before(RemoteCallImpl remoteCall) : execution(*
RemoteServiceRegistrationImpl.callService(RemoteCallImpl))
&& args(remoteCall) {
//get the security context from the RemoteCallImpl instance
and put it in a thread local
SecurityContextHolder.getContext().setToken(remoteCall.mSecurityToken);
}
}
Regards,
Radostin
On 27.10.2010 г. 21:02, Scott Lewis wrote:
Hi Radostin,
On 10/27/2010 10:19 AM, Radostin Surilov wrote:
Hi Franky, hi Scott,
Franky, thanks for letting me know about the previous discussion
- it is indeed quite similar to what I'm doing.
More about our use case - when a request to a remote service is
executed, the security context has to be passed together with
the request. The remote platform should receive the request and
put the context in a thread local (before the actual method
execution), so the security details are available for the
current call stack.
Scott, I understand that something similar should be provider
specific, so I am using ecf generic provider.
One thing to make clear: although there is no problem with using
the ecf generic provider, the code in
org.eclipse.ecf.provider.remoteservice bundle does *not* depend
upon the ECF generic provider (yes, I know the package name
org.eclipse.ecf.provider.remoteservice.generic makes it sound like
that, but that's an unfortunate package name that I now cannot
change without breaking existing API).
Rather, the org.eclipse.ecf.provider.remoteservice depends upon
the shared object API...and this API is currently implemented by
several providers: xmpp, jms, javagroups providers. This allows
*all* of these to reuse the RegistrySharedObject (and the
Request/Response classes).
The solution I found so far is based on aspects. We are weaiving
org.eclipse.ecf.provider.remoteservice so:
- When a new
org.eclipse.ecf.provider.remoteservice.generic.Request is
created the security context is put in the RemoteCallImpl
instance of the Request.
- Before each execution of the
org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceRegistrationImpl.callService(RemoteCallImpl)
the security context is get from the RemoteCallImpl parameter
and put in a thread local.
Do you see any problems with this approach or maybe suggest a
more elegant solution?
I don't see any problems with this. I think the discussion about
more elegant solution can be had around whether or not some new
API should be added to either ECF remoteservices...or the
RegistrySharedObject...but I think given your use case what you've
done makes sense. And I assume it's working for you.
If you are willing, maybe you could share the Request/Response
subclasses and the RegistrySharedObect subclasses, and that would
allow Franky and all of us to see if there are things that could
be generalized to meet several authentication use cases with
future API additions/changes.
Thanks,
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|