Alec Thomas wrote: > I've recently (re)started work on the security branch [1], using > Christian's recent Context additions. Given that the Context contains all > of the information necessary to enforce a policy decision, I think this > is a good approach. > > In the security sandbox I've made a couple of minor changes and would > like to make a few more. > > What I've done so far, and why: > > - Added a trac.resource module > - Moved trac.wiki.api.Context to trac.resource. I did this because > I think the Context is more generalised, and some auxiliary > interfaces/components are required which don't make sense being in > trac.wiki. >
Well, I also originally had a trac.context which contain this class, but I didn't have a use case for the Context class besides the wiki formatting. But I agree the idea is more general, so I'm all for that change. Note that the Context is the kind of "resource descriptor" object I was looking for to complement the resource itself. In the original TracObject idea (or even its implementation in the xref branch (1)), both the model part and the description part were mixed in the same class (the "cheap" or "complete" TracObject distinction of r2278). Now the Context is a way to address only the "description" part of the resource, not bothering about its actual data model. I hope this addresses the heavy reluctance that some had to make the resource itself aware of the "req"uest object (at least jonas is OK with that). With your proposed change, the context is now able to retrieve its corresponding data model object (ctx.object for now, soon to be renamed ctx.resource) and from the data model, it's possible to build a descriptor for it (adding the req info), so that's very good. Let me first continue by quoting the last part of your mail: > Changes I would like to make: > > - Rename the "resource" member of Contact to "realm" [2]. "resource" > currently refers to "wiki", "ticket", etc. I think it should refer > to the actual object identified (eg. WikiPage(env, 'WikiStart')). > +1, that could be done ASAP on trunk, together with the move to trac.resource, I think. > - Merge into trunk. > Well, I see a few things that could be improved upon, and maybe done differently before that happens. > - Continue converting modules. > In particular, I'd like to see how we'll convert the attachment module, in a way that would allow generic attachments (see #3068). This shouldn't require any additional interface (i.e. /not/ the IAttachmentPointProvider way) but should result from the ability to add attachment to any kind of resource (this doesn't mean we'll add an UI to do this for every kind of resource!). Now about the few modifications to what you've already done: > - Created a trac.resource.IResourceMapper interface for mapping > between resources and contexts. > - Added the trac.resource.ResourceSystem component for inspecting and > converting resources. > Note that most of the time we /already/ have the resource at hand when building the Context, so care must be taken to provide it to the context when possible (as you already do in wiki/web_ui.py), and to keep it while creating similar contexts (i.e. ctxt(abs_urls=True)). > - Added a trac.perm.IPermissionPolicy interface for making security policy > decisions, and converted PermissionSystem and PermissionCache to use this. > - Added convenience classmethod Context.from_resource(env, req, > resource) for creating a Context from a resource, such as a WikiPage > object (actually anything that can be identified via IResourceMapper). > > page = WikiPage(env, 'WikiStart') > context = Context.from_resource(env, req, page) > ... or simply `context = page.get_context(req)`, instead of the more complex hops through the IResourceMapper implementations which will end in the `identify_resource(req, resource)` of the module? > - Added Context.object, which lazily fetches the actual object > referred to by the Context (I'd like to rename this from "object" > to "resource" - more info further down). > - Added Context.perm which is a PermissionCache object (same as > req.perm) but specific to the current context. eg. > > if 'WIKI_MODIFY' in context.perm: > ... > > The context object is passed to template pages, where appropriate, > and can be used to control access: > > <py:if test="'WIKI_ADMIN' in context.perm"> > ... > <py:/if> > Ok. Also, what about allowing to check for "unqualified" permission names? E.g.<py:if test="'ADMIN' in context.perm"> which would translate to WIKI_ADMIN if context's realm is 'wiki', TICKET_ADMIN if the context's realm is 'ticket', etc. All that being said, great work so far, Alec! -- Christian (1) - http://trac.edgewall.org/browser/sandbox/trac-xref/trac/object.py --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
