launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On August 17, 2010, Robert Collins wrote:
> Its simple conceptually:
>  - use a DecoratedResultSet in bugtask queries
>  - cache the user whom we
> queried-on-behalf-of-if-we're-returning-private-bugs - use that to satisfy
> userCanView lookups in bug permission checks.
> 
> Some minor details about the arc I took, in case its of use in seeing
> patterns.

Wow, I like the simplicity of this. And I think it could supersede another 
pattern that we use in a few places, but haven't generalised.

We already found out that permission checking is expansive (since they are 
done on a single object). This especially affects listing pages that may 
contain private objects.

The way we have solved this in the past is by introducing a 
precache_permission_for_objects helper. The views that retrieve the listing of 
objects and knows that the query takes into account privacy can seed the 
permission checking cache with it.

It's used in a very few places branch listing, in another code view, and in... 
milestone! (Probably not very efficiently!)

Anyway, this has a lot of drawbacks:

- Subvert the security model by letting views declare 'these objects are safe'
- Not used in web service and in any other code paths that don't seed the 
permission cache.

Adding userCanView on the model is also the best practice now on how to 
implement checker (and have the security adapter delegate to it).

So if this new pattern flies, we should probably get rid of 
precache_permission_for_objects and use that new idio which is more general, 
simpler, and cleaner.


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.