Thanks!
On Sun, Oct 24, 2010 at 7:00 AM, Peter Ledbrook wrote:
>> Is it a known bug that the above doesn't work? I get:
>>
>> Caused by: java.lang.IllegalArgumentException: There is no filter with
>> name 'PUT]' to apply to chain [/plugin/**] in the pool of available
>> Filters. Ensure a filter
> Is it a known bug that the above doesn't work? I get:
>
> Caused by: java.lang.IllegalArgumentException: There is no filter with
> name 'PUT]' to apply to chain [/plugin/**] in the pool of available
> Filters. Ensure a filter with that name/path has first been
> registered with the addFilter met
> Just to double-check, all I have to do is treat the 'mappedValue'
> argument of isAccessAllowed() as the configuration options? In other
> words, with
>
> [urls]
> /plugin/** = authcBasic[POST,PUT,DELETE]
Is it a known bug that the above doesn't work? I get:
Caused by: java.lang.IllegalArgu
> Maybe we should provide both options. At the url configuration level
> as already mentioned, and maybe each filter also has the ability to
> decide. But given this is boilerplate, maybe it could be written in
> the top-level PathMatchingFilter (from which all other Shiro filters
> extend). Tha
Hrm - I just started thinking about it the other way too. What if you
don't want to repeat each url 4 or 5 times just because the HTTP
Method differs but the chains will pretty much be mostly the same.
Maybe we should provide both options. At the url configuration level
as already mentioned, and
> For example:
>
> /rest/**,GET = anon, foo, bar
> /rest/**,POST = authcBasic, perms[blah]
>
> or even more robust, to allow for other matching criteria later (e.g.
> header values?)
>
> rest/**[method:GET,blah:x] = anon, foo, bar
>
> This feels a little more robust to me than perhaps duplicating t
> BTW, when do you think 1.1 will be released and could I get the above
> feature into it if I implement by end of weekend? If the release is
> soon, I can try to synchronise the next Grails plugin release with it.
I think we should try to release 1.1 by the end of this month - in 2
weeks. What d
Ah, I understand now - sorry for my misinterpretation.
But I wonder if this isn't better handled some other way - like in the
request matching logic that determines which filter chain to execute.
If it is done via request matching, we don't need to duplicate this
Method-based behavior across all f
> Ah, I see - sorry you did say authentication, but I missed it anyway.
> Yes we can get this into the snapshot quickly and 1.1.0 release is
> close but farther away than just a few days.
Well, the plugin isn't going to be ready in the next few days either,
so that's OK :) The patch is attached to
Ah, I see - sorry you did say authentication, but I missed it anyway.
Yes we can get this into the snapshot quickly and 1.1.0 release is
close but farther away than just a few days.
Kalle
On Fri, Oct 15, 2010 at 1:17 AM, Peter Ledbrook wrote:
>> But HttpMethodPermissionFilter only seems to deal
> But HttpMethodPermissionFilter only seems to deal with permissions.
> It's the authentication I'm interested in. GETs and HEADs to a
> particular URL should not require authentication, but the POSTs, PUTs,
> and DELETEs should. BasicHttpAuthenticationFilter can't seem to handle
> this situation a
Hi Les,
> You could do that with authcBasic, but Kalle was pointing you to the
> HttpMethodPermissionFilter because it is much better suited for
> handling REST-based scenarios.
But HttpMethodPermissionFilter only seems to deal with permissions.
It's the authentication I'm interested in. GETs and
Hi Peter,
You could do that with authcBasic, but Kalle was pointing you to the
HttpMethodPermissionFilter because it is much better suited for
handling REST-based scenarios.
Remember 'authcBasic' is for handling authentication. Once
authenticated, the HttpMethodPermissionFilter performs authoriz
> See org.apache.shiro.web.filter.authz.HttpMethodPermissionFilter
Just to double-check, all I have to do is treat the 'mappedValue'
argument of isAccessAllowed() as the configuration options? In other
words, with
[urls]
/plugin/** = authcBasic[POST,PUT,DELETE]
I can add
public isAcce
See org.apache.shiro.web.filter.authz.HttpMethodPermissionFilter
Kalle
On Thu, Oct 14, 2010 at 7:10 AM, Peter Ledbrook wrote:
> Hi guys,
>
> I'd like to add support for method-specific Basic authentication, but
> I need some hints on how to implement. The basic idea is that I want a
> rule like
Hi guys,
I'd like to add support for method-specific Basic authentication, but
I need some hints on how to implement. The basic idea is that I want a
rule like:
[urls]
/plugin/** = authcBasic[POST,PUT,DELETE]
In other words, I'd like to enable basic authentication for the write
methods,
16 matches
Mail list logo
