[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
> (http://hg.logilab.org/master/cubicweb/file/48f0ff3e2a32/web/component.py#l506)
> uses user_rql_callback to add/delete a relation.  The 'add a relation'
> functionality is e.g. used by AddRelationView
> (http://hg.logilab.org/master/cubicweb/file/48f0ff3e2a32/web/views/ajaxedit.py#l27)
> 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
> cube.

One thing is unclear to me : on what criteria do we want to forbid some
actions ?
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 mailing list