[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] user authentication and user dependent services
|
On 6/30/2015 11:21 PM, Peter Hermsdorf wrote:
<stuff deleted>
If I've understood your use case correctly (above questions), then I
can think of a couple of approaches. One that I've done myself is to
have some other OSGi service for storing/retrieving the association
between the clientID and the username/pw/auth info. Then you could
store that association away upon connect/disconnect (or at some other
point in the protocol...e.g. if you have some other login service),
and then look it up/check it in response to a remote call. There is
a way with existing API to get the clientID/fromID for every remote call.
That might be a way. But then I need some API to get the clientID of
the "current" caller to find the authentication information that got
stored on login....
The IRemoteServiceCallPolicy interface has the clientID that is the
'containerID of the remote caller', so it is passed to those that
implement that interface.
Another way would be to keep the above association info not as a
separate service but as some state on the host container. Perhaps
not as clean IMHO, but possibly serviceable.
What came to my mind as a cool solution is doing something similar to
what is done with Servlets where you can get stuff injected in your
Servlet Resource Class. eg.
@Context
HttpServletRequest request;
and then use the request(or session or whatever else ...) to get all
kind of information regarding the request and caller.
This saves the implementor from calling an API directly, is loosly
coupled and can be tested more easily.
I would be willing to add interfaces to the RegistrySharedObject to
expose information about the remote call (i.e. request/response, etc),
if you or others think that would be of general usefulness.
Scott
