[Cubicweb] user callbacks, rqlcontroller, ajaxfunc, and schema permissions
Christophe de Vienne
christophe at unlish.com
Tue Mar 11 14:44:45 CET 2014
Le 11/03/2014 14:25, Julien Cristau a écrit :
> Hi all,
> as part of making it easier to run multiple instances of a cubicweb
> application, we're trying to sanitize our use of server-side state.
It is also required to have persistent sessions in a single-instance
> The user_callback mechanism in cubicweb stores a function in the session
> data, that can then be invoked in a later web request. That mechanism
> is, shall we say, less than ideal in the context of session data being
> shared across processes, so that "later web request" could be served by
> a different backend.
> I can think of a few ways to deal with this:
> 1. for each of the call sites, instead of storing the callback in session
> data, store the necessary state (basically the current callback's
> arguments), and write a dedicated ajaxfunc that retrieves this state
> from session data and then uses it
The less data we store in session the better. In some very specific
cases (a authentication-less basket for example) a small amount of it is
needed, but I really think we should seldom use session datas.
> 2. same as above, except pass the state back and forth as part of the
> generated link and get it back as form data
This is, for me, clearly the best approach.
> As one specific example, EditRelationMixin
> uses user_rql_callback to add/delete a relation. The 'add a relation'
> functionality is e.g. used by AddRelationView
> which lets the user choose pretty much any relation they want to add
> through url params.
> Trying to replace user_rql_callback in this case (using approach 2.
> above) led me to https://www.cubicweb.org/revision/3624373; it has the
> downside over the current approach that it potentially opens up things the
> developer didn't want to allow (which I would argue would be a bug in
> the application's permissions setting, but...). It is also kind of a
> less generic version of what's already present in the rqlcontroller
One thing is unclear to me : on what criteria do we want to forbid some
If it only depends on the user, we don't need state-data, and if the
schema permissions are not enough then some selectors set at the right
place should do the trick.
> So my questions would be: do you think it's ok to rely on the app schema
> to define what should and shouldn't be allowed in these controllers? Or
> should a replacement for user_callback aim to reimplement exactly the
> current functionality?
I think it is ok it the vast majority of case. If the schema security is
not properly set, it would not be enough to add restrictions only there.
> If we do rely on schema permissions, I think it
> would make sense to merge rqlcontroller in to cubicweb core.
The less things in the core the better.
I guess a merge would make sense if it gets installed on all the
instances we know of, although even with that I prefer modularity.
And if it is it should not be activated by default (a lot of things
should be deactivated but that is another debate).
My 2 cents,
More information about the Cubicweb