understood. but then my problem remains unsolved, let me elaborate the
problem again,
Basically I want to authorize the user based on PathParams, to take this
decision, I need 3 things at one place 1. The Principal 2. PathParams 3.
Roles to check against (Provided via annotations)
With the suggested code, I can look at the PathParams in my subclassed
authenticate but I neither have the Principal nor the Role to check
against. One solution is to put PathParams into my principal subclass, so
that its available to me inside authorizer.authorize, but looks kind of
hacky.
On Wednesday, July 13, 2016 at 10:49:17 AM UTC+5:30, Evan Meagher wrote:
>
> AuthFilter instances are shared by all application threads within a
> Dropwizard server, so they need to be thread-safe. Reassigning
> `authenticator` within the `filter` method would risk leaking
> `ContainerRequestContext`s across threads handling different requests.
>
> All your AuthFilter subclass should have to do is override the
> `authenticate` method to inspect the request context before passing through
> to `super.authenticate`:
>
> public class PathInspectingBasicAuthFilter<P extends Principal>
> extends BasicCredentialAuthFilter<String, P> {
> @Override
> protected boolean authenticate(ContainerRequestContext
> requestContext, C credentials, String scheme) {
> // Inspect the PathParams within `requestContext` and maybe return
> false.
> ...
>
> return super.authenticate(requestContext, credentials, scheme);
> }
> }
>
> Note that I took the liberty of extending `BasicCredentialAuthFilter`,
> since based on your example you appear to be using basic auth.
>
> On Tue, Jul 12, 2016 at 9:22 PM, Saumitra Bhave <[email protected]
> <javascript:>> wrote:
>
>> Hi Evan:
>>
>> Thanks a lot for your help, I got the idea from your post but not sure if
>> I implemented it right, following is what I have done based your suggestion.
>>
>> RequestAwareAuthFilter.java
>> "
>>
>>
>> public class RequestAwareAuthFilter<P extends Principal> extends
>> AuthFilter<String, P> {
>>
>> private AuthenticatorFactory<String, P> authFactory;
>>
>> private RequestAwareAuthFilter(AuthenticatorFactory<String, P>
>> authFactory) {
>> this.authFactory = authFactory;
>> }
>>
>> @Override
>> public void filter(final ContainerRequestContext requestContext) throws
>> IOException {
>> final String credentials =
>> getCredentials(requestContext.getHeaders().getFirst(HttpHeaders
>> .AUTHORIZATION));
>>
>>
>> authenticator = authFactory.get(requestContext);
>>
>>
>> if (!authenticate(requestContext, credentials,
>> SecurityContext.BASIC_AUTH)) {
>> throw new
>> WebApplicationException(unauthorizedHandler.buildResponse(prefix, realm));
>> }
>> }
>>
>> @Nullable
>> private String getCredentials(String header) { ... }
>>
>> public interface AuthenticatorFactory<C, P extends Principal> {
>> Authenticator<C, P> get(ContainerRequestContext requestContext);
>> }
>> }
>>
>> "
>> Does that make sense? Basically its very much inspired by the existing
>> OAuthFilter, but in this case, the builder provides a way to set
>> 'authenticator factory' instead of a singleton authenticator, then I create
>> a new Authenticator with request context in each filter call.
>>
>> This allows me to inject the same request context into the Principal
>> subclass inside 'Authenticator.authenticate(credentials)'
>>
>> Is this the best way to achieve what I need? or am I over engineering
>> things here?
>>
>> Thanks again,
>> Saumitra
>>
>> On Tuesday, July 12, 2016 at 8:06:47 AM UTC+5:30, Evan Meagher wrote:
>>>
>>> Can you provide relevant snippets of your code, please? If you're using
>>> AuthDynamicFeature, then you're presumably still creating an AuthFilter to
>>> pass to its constructor. In which case you still have access to the
>>> `ContainerRequestContext` within `AuthFilter.authenticate`.
>>>
>>> If you're relying on an AuthFilterBuilder to create a filter for use
>>> with AuthDynamicFeature, then perhaps you can simply manually create an
>>> AuthFilter subclass in order to regain access to `ContainerRequestContext`s.
>>>
>>> On Mon, Jul 11, 2016 at 1:28 PM, Saumitra Bhave <[email protected]>
>>> wrote:
>>>
>>>> I just moved from custom AuthFilter to dropwizard's authentication
>>>> Feature, One problem I am facing is that I can not access "PathParams" in
>>>> the authorize method.
>>>>
>>>> Basically, my requirement is simple, in that, For Eg. User A has signed
>>>> in and he has access to modify user B, I have this information stored in
>>>> the UserPrincipal at the time of authenticate call. Now, I want A to be
>>>> able to access PUT /users/A and PUT /users/B but not anything else.
>>>>
>>>> In the custom implementation, I used to store
>>>> UriInfo.getPathParameters() into the security context, and I could use
>>>> user
>>>> principal and the Path together to resolve complex Authorization queries.
>>>>
>>>> Is there anyway I can achieve the same using DropWizard's
>>>> AuthDynamicFeature?
>>>>
>>>> Regards,
>>>> Saumitra
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "dropwizard-user" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Evan Meagher
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "dropwizard-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Evan Meagher
>
--
You received this message because you are subscribed to the Google Groups
"dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
