Re: [WAC] regexps in WebAccessControl

<snip>
Extending slightly what Ruben wrote - Nothing wrong with it, that's what
WebACL is - the proposal is to look at the lexical representation of the
URI and base access control on whether the URI regexp matches not, or
perhaps further, to base access control rules on specific server side
directory structures which are only known behind the interface.
</snip>

the URL interface in most implementations I work on rarely has any
(meaningful) relation to the storage model on the server. keep in mind most
of the work i do treats URIs as transient identifiers, not meaningful
names. I suspect that is why my POV may not match well with what's
discussed here; fair enough.

<snip>
If we consider the case of generic data storage, then WebACL rules may
often be sent sent by the client, for the server to apply to the resource,
in relation to resources they control - would we want clients to have to
know about implementation details hidden by the interface, such as
directory structures (or even if there are directories!).
</snip>

based on a reply from Ruben, i think what we're on about here is an
implementation/optimization detail and that's fine.  looks like i
misunderstood Ruben's initial reply.

in cases where you have some person in the role of defining security using
a client app that has the power to apply security rules, i would *assume*
that person *does* have knowledge about the URI structure in general (e.g.
whether /admin/.* is a reasonable rule to apply to a URI space). if that's
not the case (e.g. those applying rules have no knowledge of the URI space
save the one URI they are attempting to secure), then certainly any use of
regular expressions is a bad idea.

again, these seem like implementation details local to the use case, but i
might be missing the point.


mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen


On Sun, Nov 18, 2012 at 1:12 PM, Nathan <nathan@webr3.org> wrote:

> mike amundsen wrote:
>
>> ok, can't let this go....
>>
>> <snip>
>> This couples your access control to your URI structure.
>> </snip>
>> yes, it does.
>>
>> i *always* (as far back as i can remember) secure the interface (resources
>> on the server) via the URL. in fact, i use:
>>
>> Access[true/false] = (URL + Protocol_Method + User_Identity)
>>
>> for first-line authorization.
>>
>> tell me why this is a problem.
>>
>
> Extending slightly what Ruben wrote - Nothing wrong with it, that's what
> WebACL is - the proposal is to look at the lexical representation of the
> URI and base access control on whether the URI regexp matches not, or
> perhaps further, to base access control rules on specific server side
> directory structures which are only known behind the interface.
>
> If we consider the case of generic data storage, then WebACL rules may
> often be sent sent by the client, for the server to apply to the resource,
> in relation to resources they control - would we want clients to have to
> know about implementation details hidden by the interface, such as
> directory structures (or even if there are directories!).
>
> To me, regexp matching seems like it may be fairly useful, but something -
> which I can't quite vocalise (other than uri opacity axiom), and focusing
> on uri structure - is worrying me a little about it.
>
> This is an area you understand well Mike, so any input you have as to what
> the positives and negatives are would be greatly appreciated.
>
> Cheers,
>
> Nathan
>
>
>  On Sun, Nov 18, 2012 at 10:49 AM, Nathan <nathan@webr3.org> wrote:
>>
>>  Ruben Verborgh wrote:
>>>
>>>   It is often useful to be able to specify that all resources in a
>>>>
>>>>> collection ( a directory ) or a whole namespace (say all resources
>>>>> under /user/jack/.*
>>>>>
>>>>>  This couples your access control to your URI structure. I’m not sure
>>>> you
>>>> want to do that.
>>>>
>>>>  Agreed.
>>>
>>>
>>>
>>>
>>
>