Am 08.10.2007 um 19:11 schrieb Christian Boos:
> A. The fine grained permissions
>
> On Oct 5, 7:10 pm, Christopher Lenz <[EMAIL PROTECTED]> wrote:
>> To quote:
>>
>> "As fine-grained security and permission checks are becoming the
>> rule in Trac, one shouldn't be able to access a resource without the
>> appropriate credentials."
>>
>> I *strongly* disagree with this. That *may* be something to think
>> about for a future release, but most definitely not for 0.11.
>
> Well, there are compelling arguments in favor of doing it this way,
> as brought up by osimons in
> http://trac.edgewall.org/wiki/TracDev/ContextRefactoring#osimons.
>
> Excerpt:
>
> "A ticket today can be accessed through navigation/request
> to ticket, queries, macros, links and countless other ways.
> In each and every instance I need to remember to check
> permissions. Always. And in the same manner. Some sort of
> custom ticket box macro that gets this wrong will spill all
> the beans."
I'm not saying the goal isn't worthy, I'm putting my veto in for
doing anything in this direction at this time on trunk.
We're in a mess with the 0.11 release plan. Adding new requirements/
goals this late in the process is not going to help clean up the mess.
>> And the whole concept of "resources have to be created through the
>> permission system" is wrong IMO.
>
> "wrong"? - well, not according to the reasoning above.
From an API design point of view, from the perspective of layering
responsibility, it's wrong.
Calling perm('wiki', 'WikiStart') to acquire some kind of resource
descriptor/representation/whatever is a counter-intuitive design IMNSHO.
Now, something like ResourceManager.get_resource('wiki', 'WikiStart',
perm=perm), where perm is optional, might work for me, but again, I
don't think we should be having this discussion at this point. Create
a branch that's scheduled for 0.12 if you want to, but let's please
drop this (completely new) goal for 0.11.
Again, to make this really clear, I'm not arguing that we shouldn't
have a layer that automatically restricts access to resources by
permissions. I'm saying that we need to get 0.11 out, and we should
concentrate on what we have, not add new things to the (already
consufing) mix.
>> But that's not the point. The point
>> is that we should not be thinking about doing anything like that for
>> 0.11. Both Alec and myself have stated early on that we think this
>> was out of scope for the release.
>
> I think that moving the permission checks down to the data model
> layer is something that can be done after 0.11, yes.
> However, I do think that providing an API for ensuring that all
> accesses to the resources are subject to fine grained permission
> checks is precisely what we wanted to have for 0.11.
Really? I think the goal of the security branch was to *allow* fine-
grained security to be applied. Nothing more.
>> My idea (and I think I'm not alone here) was that we should go back
>> and fix Context by removing/simplifying. What you're proposing here
>> seems to go in a totally different direction.
>
> If by "fix Context by removing/simplifying", you mean that we should
> remove all the enhancements brought by introducing more support for
> generic resources in Trac, then I think it's more a conflict of
> vision.
By "removing/simplifying" I mean that I think the current design of
the Context layer is overly complicated and too indirect, and we
should seek to simplify it so much that the issues it was set out to
resolve remain addressed, but with a lighter *and* cleaner design,
providing better separation between layers and responsibilities.
> If you're talking about accessing the resources from the permission
> system, then you're right, it's a different direction than the one
> taken earlier during 0.11dev, but it's simply because no one thought
> about that idea before. As we're talking about introducing a new API
> anyway, I don't see the problem about doing things that way if there
> are compelling reasons for it.
[snip]
The problem I see is that if we don't remove that aspect from this
dicussion, this thread will still be going back and forth in a year
from now, and there'll still be no 0.11 release.
What's the problem with doing this work on a branch (scheduled for
0.12 or later), leave the application of security restrictions to the
UI code (as it is currently and always has been), and concentrate on
the other issues for now?
> B. The rendering context
>
>>> On Sep 27, 7:15 pm, Christopher Lenz <[EMAIL PROTECTED]> wrote:
>> Anyway, I strongly doubt we'll need to identify the "resource/
>> context" in which some other resource is being rendered. The only use
>> case I can think of are relative links (as in ../foo instead of /bar/
>> foo), and those are more trouble than they're worth. That's not to
>> say that the idea of a "rendering context" isn't needed, just that
>> that context doesn't need to know about the (pseudo-)resource in
>> which it's being used.
>
> Right now, the rendering context needs to know about the current
> resource for the following reasons:
>
> - rendering relative links (./Child, ../Sibling and #Anchor)
Ok, so you're rendering the wiki text that is attached to a specific
resource, say a wiki page, *somewhere*. Now, having the wiki
formatter, the link resolvers, the processors, etc know about that
resource (the wiki page) is of course what the point of introducing
context was all about. I'm not saying that we don't need this, but I
can see how what I've said was easy to misunderstand.
What I mean that we don't need is, for example, whether a snippet of
wiki text that actually belongs to a ticket or wiki page is being
rendered in the timeline or in the search results, for example. The
only part it needs is to be informed about the resource it belongs to.
(What I meant with "relative links" in the paragraph you quoted were
relative HTTP URLs in the generated HTML markup.)
[snip lots]
> - More generally, the rendering context will be used to
> progressively
> get rid of the Request object in the rendering layer, and be used
> to simplify the mimeview API
Okay, I can definitely see a need for that, so what are you proposing
the rendering context should look like?
>>>> Well, data model instance creation is costly especially in the
>>> timeline event providers and search providers, but also in report
>>> and
>>> query results.
>>
>> Well, elsewhere in my mail I said that there should be ways to get
>> display_name etc without going through a DB lookup. Just adding a
>> get_resource_info() method (or similar) to the IResourceManager
>> interface I proposed would do the trick, while still not requiring
>> the use of resource "descriptors" as opposed to simple identifiers.
>
> This is mainly a matter of convenience and future extensibility.
> We could of course have a `resource_url(resource_id, href)` function
> instead of a `resource.url(href)` method, but I think we will have
> more and more code working at the generic level, and this convenience
> will pay off then (I think it already does).
You can always layer a convenience layer above a more direct, lower-
level layer. The reverse is not true.
And in fact, layering a convenience class on top of lower-level
infrastructure improves flexibility, as opposed to reducing it.
> It is true that /when/ we have the model around, we already have some
> kind of facilities to access the id, but not in an uniform way:
> ticket.id for tickets, page.name for wiki pages.
> And we don't even have a way to get the realm information!
Well, we don't have now, but I proposed to add simple properties to
the model objects, i.e. Ticket.resource, WikiPage.resource, etc.
> We /do/ have some modules that specifically handle /any/ resources:
> those are the timeline and search modules (and more recently the
> attachment module). However they have the advantages of being "core"
> or "well-known" modules, so that it's the responsibility of resource
> managers to implement the interfaces offered by those modules.
> But what if you want to provide as a plugin another module that
> handles
> resources in a generic way? Even if you could write adapters for the
> core/well-known resources, you can't expect to cover all kind of
> resources this way.
Okay, so we have ITimelineEventProviders, ISearchSources, and all
that, and you're saying you think they're should be something better,
I guess (correct me if I got you wrong); there shouldn't be a need to
write those "adapters" for resources plugins add to the system.
Plugins should tell Trac what kind of resource they are providing,
and Trac (or yet other plugins) should figure out everything
automagically or something.
I must say that I'd consider that kind of change/vision outside of
the scope of even Trac 1.0.
But rereading what you're saying, I don't see anything that can be
accomplished with a Resource class, but not with simple tuples and a
component exposing an IResourceManager extension point, as I had
proposed. Again, a convenience could be put in place on top of that,
if it's deemed benefitting. Possibly later. I just think it's much
cleaner to clearly separate the layers here.
[snip]
> The way forward?
>
> I propose to create a sandbox/context-split branch, where I finalize
> my current version of the changes. Most of the work is already done
> (about 1700 "hunks"), there's no "Context" class left, it works
> reasonably well and there's full coverage for fine grained
> permissions
> on all the modules.
I'm only +1 on such a branch if it does not include the permission
stuff, as explained above.
> /If/ we decide to go for tuple-based resource identifiers, using that
> branch as a basis will make the work significantly simpler than
> starting
> again from trunk.
That sounds reasonable.
[snip]
> I'm just afraid that the situation will repeat itself for 0.12, as
> from
> what I understand, you're probably opposed to some other major design
> proposals of mine, like the generic Trac stuff. This will then lead to
> the question of which approach will the project take, the one I defend
> or the one you defend (which, I admit, I know little about).
We will need to sort this out *somehow* for the future. Here's what
*I* want: us to release a 1.0 version sometime in this decade, and
postpone any big vision shifts until after that point.
What I want is to fix the big problems we still have, for example
I18n or documentation/help. I don't yet want to think about multi-
project support, a generic resource system used throughout the code,
or big changes to the plugin/component system.
There's a life after 1.0, if we even ever reach that point.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
