[Cubicweb] user callbacks, rqlcontroller, ajaxfunc, and schema permissions
sylvain.thenault at logilab.fr
Tue Mar 11 15:58:18 CET 2014
On 11 mars 14:44, Christophe de Vienne wrote:
> Le 11/03/2014 14:25, Julien Cristau a écrit :
> > 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.
+1 on both point. Keep the state way from the server.
> > 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.
* after years of experiment, we're currently moving toward more confidence into
* feel free to not reimplement the exact same functionality
* if there are still corner cases, let's discuss about them
> > 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).
I agree with Christophe points and yours, and I think we want both :)
I would let rqlcontroller in its own cube right now, so it may grew up there. In
the mean time, define necessary ajax callbacks / controller as you propose. Once
we will be ready for more REST api in CW, we'll much probably want them in the
core and reimplement some existing things using them (ie more for less :).
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
CubicWeb, the semantic web framework: http://www.cubicweb.org
More information about the Cubicweb