BTW, Just for completeness, I cannot subclass any of the DropWizard
provided AuthFilters as all of them have private constructors only. I am
trying all your suggestions by extending AuthFilter directly.
On Thursday, July 14, 2016 at 12:06:33 AM UTC+5:30, Saumitra Bhave wrote:
>
> 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]>
>> 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].
>>> 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.
