geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <jga...@gmail.com>
Subject Re: Jacc questions
Date Wed, 18 Mar 2009 16:36:41 GMT
On Tue, Mar 17, 2009 at 1:56 PM, David Jencks <david_jencks@yahoo.com> wrote:
>
> On Mar 17, 2009, at 10:30 AM, Jarek Gawor wrote:
>
>> Hi,
>>
>> Looks like with the Jacc API there is no easy way to set multiple
>> types of handler data objects on the same thread at the same time (see
>> PolicyContext.setHandlerData()). That is, if for example, if a servlet
>> makes a ejb call, from within the ejb we won't be able to retrieve the
>> HttpServletRequest object using the PolicyContext API since the
>> HttpServletRequest object will be replaced with the ejb call info
>> object on the thread.
>>
>> So what's the best way to deal with this problem?
>>
>> One way to solve it, it would to set the handler data object to some a
>> Map and set the handler data objects on the map. That would work as
>> long as nothing else calls PolicyContext.setHandlerData() and replaces
>> the map with some other object.
>>
>> Another way to solve it, it would be to create a GeronimoPolicyContext
>> class (or something like that) which would support setting multiple
>> types of handler data objects on the same thread at the same time (e.g
>> GeronimoPolicyContext.setHandlerData(key, data)) AND modify Geronimo's
>> PolicyContextHandlers to use GeronimoPolicyContext to get the right
>> object for the handler. But with this solution we might be ignoring
>> what's set using PolicyContext.setHandlerData().
>>
>> Thoughts?
>
> The alleged purpose :-) of the policy context handler data is to provide
> context info for permission evaluation.
>
> To me the main problem is that in this scenario:
>
> servlet (servlet request)
>>>ejb (ejb method params)
> return to servlet (still have ejb method params)
>
> the servlet can't use the servlet request to evaluate role-ref permissions
> after the return from the ejb.

I see, that's a problem too.

> We could solve this problem by having each data handler have its own thread
> local and when you call setHandlerData it delegates to all the handlers
> which will store it if its the right type.  This solves the "lots of info at
> once" problem but prevents you from clearing the data when you are done
> unless we have some custom object for each handler that it recognizes to
> clear its own data.
>
> So the handler would have a method like
>
> public boolean setHandlerData(Object data) {
> if (data instanceof HttpServletRequest) {
>  servletData.set(data);
>  return true;
> } else if (data == CLEAR_OBJECT) {
>  servletData.remove();
>  return true;
> }
> return false;
> }

Or maybe we should just expose set()/unset() type of methods on each
PolicyContextHandler implementation (to set/unset the thread local
variable) and just call those methods within our code.
Otherwise, (and if I understand you right) we would have to modify how
PolicyContext.setHanderData() works to have it call all the registered
handlers. And that would require some new interface to put on the
handler implementations or some reflection code.

Jarek

Mime
View raw message