Lazy load Identity object

[mviamari]

Currently, the identity object is loaded on each request using Principle._on_before_request and Principle.identity_loaders.

The problem is that the identity is not already required for each request and each access to the identity implies an access to the session data.

Ideally, the identity would only be loaded when needed.

Is this a planned feature? Something that I could help out with?

[joelcox]

I think I'm running into somewhat the same problem. Principal looks really neat, but as far as I can see from the docs, Principal requires me to load all the permission as soon as the identity_loaded signal is fired.

This model breaks down in the following cases:

• When you initiate Principal with the use_sessions=False option, Principal loads all the permissions on each request instead of potentially retrieve those from the session.
• If you've a lot of objects you want to add access control to, you'll have to retrieve all these records from the database and add those to the identity. Wouldn't it be nicer to specify a callback function which gets called when you need to check for authorization?

Please correct me if I made any wrong assumptions about how Principal works, I only read the docs and skimmed the underlying code.

[mattupstate]

@mviamari @joelcox There is an issue for this already. See #6. Unfortunately I'm still trying to figure out how to tackle this. Part of my research has been looking into well established ACL systems and how they work in the context of a web application.

[joelcox]

Sorry Matt, how could I've missed that! Keep up the good work.

[mviamari]

@mattupstate I think that the issue I'm referring to is subtly different than #6, although I can certainly see how they might be solved together. (Or maybe I didn't fully understand the issue as presented in #6.)

My issue is that since the core of the Identity object is knowing who the requesting user is, which in turn is read from the session, every request reads from the session because the Identity object is assumed to exist before the request is processed. (It is created with the identity_loaders called on the before_request hook.) Thus, even for requesting resources that have no Needs, and maybe do not even require an authenticated user, there is a session read.

This in particular can be problem if the session is persisted using a backend rather than the default direct serialization in the cookie (creates unnecessary reads) or if session accessed checks are used determine if a Vary:Cookie header is needed when returning the response (very useful when using something like Varnish to cache responses).

A possible solution here would be to delay the execution of the identity_loaders until the identity object is accessed directly. I think this can be done separately from the loading of the provides for the Identity object so as to prevent a future conflict with #6.