On 9/25/07, John Hampton <[EMAIL PROTECTED]> wrote:
> osimons also suggested the possibility of using URI paths for the
> resource descriptors. For example: 'attachment/ticket/2048/2048.patch'
>
> cboos raises concerns about this due to the need to parse the path each
> time the descriptor needed to be evaluated and the ambiguity of the use
> of '/'.
>
> While I kind of agree with the parsing bit, I don't agree with the
> ambiguity. The simple solution would be to URI encode the string. Then
> '/'s are always separators, etc. However, it could lead to some really
> ugly resource descriptors.
Hi, thanks for your summary of the issue. I was starting to get a
little lost too.
Yes, in an earlier implementation I had of fine-grained permissions,
URI paths like that were used as resource identifiers, and it quickly
became cumbersome. This is in fact still in use in the database, but
they are quickly parsed into something more useful. So if one were to
store resource identifiers in a database it's not terrible, but some
more useful data structure is needed for use by the API. I haven't
decided which I like better of the solutions that have been suggested
at this point. Of course, you still want a normal method of
converting a resource identifier to a URI.
> The biggest problem right now, is that many
> calls are made without specifying a realm. I think that while a full
> resource descriptor may not be necessary, a realm should be required.
>
> cmlenz suggests:
> {{{
> 1. req.perm(realm, id=None)
> 2. If realm is a list, treat it as a fully specified resource descriptor.
> 3. Otherwise treat (realm, id) as the descriptor.
> }}}
I really like this idea. A little while ago I was tasked with
enhancing the permission system to allow ticket permissions to be set
based on a ticket's type (defect, enhancement, etc). Usually, when
checking such permissions, a specific ticket resource is dealt with.
But sometimes it isn't. For example, when checking the TICKET_CREATE
permission for whether or not the 'New Ticket' menu item should be
shown, as long as they can create tickets of one type, the
check_permission function should return true. In other words, it's
useful to check permissions by realm as well as by resource.
> the main entry point (other than backwards compatibility). He proposes
> the rendering context [see below about link rendering] as a possibilty
> for storing the permission info. Or creating a `User` object to wrap
> the req.authname and permission cache.
I have also implemented something like this with success on a
different project. It used an LRU cache of User objects that stored
each user's permissions. Unfortunately, it was still necessary to
keep a timestamp in the database each time a user's permissions were
updated, and to check that timestamp every time the user's permissions
were looked up. But it was still fairly efficient--it reduced several
more time-consuming operations per request to one small DB query and
hash table lookup. Trac's permission system is much more lightweight
to begin with though, so I doubt anyone would want that added
complexity.
> I agree that if the permissions aren't tied to a request (which I agree
> they shouldn't) then using req.perm is kind of counter-intuitive.
> However, due to the need to release 0.11 sometime this millennium, I
> think that sticking with req.perm is the better choice. I think that a
> separate class make sense, but should be slated for 0.12 or 0.13.
Yeah, it's useful sometimes to check a user's permissions outside the
context of a specific request. But it will have to stay for now, and
req.perm could still easily be kept in the future for backwards
compatability.
Erik
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
