Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: les.hazlewood@anjinllc.com
In-Reply-To: <AANLkTinn7b06e2L_2H0vUQ01i=jua2ffDMPFbCKX-mVV@mail.gmail.com>
References: <AANLkTinHe1Us+CFZpx0vXaunRW8kVgDrMDQjozeb5-9A@mail.gmail.com>
	<AANLkTi=9pqxaJMcEJaE-ATota9qPtoMXetLaxHphfNdu@mail.gmail.com>
	<AANLkTik5Zm4O7fWucUCP7oA3CNs5GcWcWjs-4G3-kqTF@mail.gmail.com>
	<AANLkTimUtFJC+eun4j9UQt67OG8cFMosMEZ4E7sSMhqr@mail.gmail.com>
	<AANLkTi=8NoQuPTqCJQbs3z7UxQ6RXNoYzpxHm7cSuCKf@mail.gmail.com>
	<AANLkTi=dBM+yu4ZYeugnvBUyih1LAPk0UYveRuLCR_=y@mail.gmail.com>
	<AANLkTinn7b06e2L_2H0vUQ01i=jua2ffDMPFbCKX-mVV@mail.gmail.com>
Date: Fri, 15 Oct 2010 15:23:14 -0700
Message-ID: <AANLkTi==u=YWiHqPquvbHWuf7tmXndC7objn_RpQvpfj@mail.gmail.com>
Subject: Re: HTTP method-dependent Basic authentication
From: Les Hazlewood <lhazlewood@apache.org>
To: dev@shiro.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 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).  That way an end user can use what they prefer or what the
situation deems most appropriate.  Thoughts?

As to the syntax, my preference is that the request path + method be
specified on the left-side of the equals sign since those two together
define the matching criteria.  After a match is made, the right-hand
side is the chain to be executed.  This approach plays nicely with the
existing FilterChainResolver/FilterChainManager implementations.

How about:

/rest/**[GET,POST,...] =3D foo, bar, baz

The reason I propose this format is that there is no equals sign,
space or colon before the chain definition:  if you want to use an
equals sign, colon or space in the key, you have to escape it, since
that's how INI and .properties parsing works.  That can look pretty
ugly IMO.  It also maintains a congruent configuration concept (the
brackets) that is used with the filters already.

My .02,

Les

On Fri, Oct 15, 2010 at 2:42 PM, Peter Ledbrook <peter@cacoethes.co.uk> wro=
te:
>> For example:
>>
>> /rest/**,GET =3D anon, foo, bar
>> /rest/**,POST =3D authcBasic, perms[blah]
>>
>> or even more robust, to allow for other matching criteria later (e.g.
>> header values?)
>>
>> rest/**[method:GET,blah:x] =3D anon, foo, bar
>>
>> This feels a little more robust to me than perhaps duplicating this
>> stuff across the HttpMethodPermissionFilter or Authc filters...
>>
>> Thoughts?
>
> I agree that whether a filter should apply to a particular HTTP method
> is orthogonal to the filter implementation. Attaching it to the rule
> itself does make sense. To my mind, it's simply a question of what
> syntax to use.
>
> =C2=A0 =C2=A0 GET:/rest/** =3D ...
> =C2=A0 =C2=A0 POST,PUT,DELETE:/rest/** =3D ...
>
> or
>
> =C2=A0 =C2=A0/rest/** =3D anon, foo, bar -- GET
> =C2=A0 =C2=A0/rest/** =3D authcBasic, perms[user] -- POST,PUT,DELETE
>
> All sorts of options available.
>
> Peter
>