[Cubicweb] Pyramid & Cubicweb sessions/authentication integration

Christophe de Vienne christophe at unlish.com
Mon Jul 7 15:09:17 CEST 2014

Le 07/07/2014 13:02, Aurélien Campéas a écrit :
> On 07/07/2014 12:44, Christophe de Vienne wrote:
> [...]
>>> We should clarify this web-session vs repo-session thing.
>>> There is exactly ONE session concept right now in Cubicweb.
>> Here is my view on this matter :
>> - A repo session is something I am trying to define. It allows multiple
>> connections to share an identity and some datas. These data have a
>> purpose which should be limited to specific interactions with the
>> repository.
> The repo session provides db connections with credentials.
> It is true that session.data is mostly used by the web side
> but there is nothing inherent to the web.
My point is that session.data should not be mistaken for a web session data.

>> - A web session is a web specific concept. It allow a web application to
>> store (preferably small) informations in some storage, and access these
>> informations on the server side whenever the server is handling an
>> http-request coming from a same web-browser session.
>> The two should be different because the web is only one mean to access
>> the repository (although being by far the most relevant).
>> Typically, in a shell script, the notion of websession is irrelevant,
>> but we may need to use the repo session data. I don't have real-life
>> example of that, but it seems to be usable to send informations to some
>> hooks.
> I disagree with such an excessive partitionning of roles given to
> sessions given the context. We recently suppressed the "repo/web"
> fence for good reasons.

Letting the hooks access the web app context (ie the web request) in
some cases where it is needed is a different matter.
What bothers me is imposing a session data system that is shared between
the repository and the webapp.
The (web)application should be able to use any session data system.

>> It should be different also because the web-session datas have nothing
>> to do in the repo memory, and even less be accessible to the hooks or
>> any repo-only appobject.
> Real life begs to differ :)
> What we really need is to divorce out the Request from the Connection
> in the web side.
> Notification hooks, for instance, will likely appreciate
> acessing the originating web request.

Mail notification hooks may need to access the web request, but it is
not related to whether or not should the session data be shared between
the session repo and the (web)app session.

I still fail to see real life examples that requires a session concept
in the repository.

>>>>> Anyway, the session is accessible through cnx.session so what's
>>>>> the problem ?
>>>> I have no problem, I am just trying to have a clear vision of the
>>>> required scope of the repo session, and if we can un-correlate it from
>>>> the websession.
>>> Sessions are not "web" or "repo", they just are (imho).
>> I think this would means : there is no "repo" sessions. Only an identity
>> voucher to open new connections for the same user, and connection .data
>> that are readable by the repo appobjects but not shared among connections.
> There is something like hidden use cases in this discussion, which I
> would like to have first in plain sight.

Not really : as this thread subject says, we are talking about pyramid &
cubicweb integration, which means we need to evaluate what things belong
to the web framework part, and what things belong to the datas & views part.

And the session concept being very well implemented with a clear api in
pyramid, I would like to use it and be sure about what it means for the
cubicweb ecosystem.

> Something like: we want sessions, but NOT provided by the cubicweb repo.
> (e.g. we make a mostly non-database app with cubicweb).
> Right ?
Somehow yes, but my concern is more about letting the user choose as
much things he wants.

And yes I would like to use sessions not provided by the cubicweb repo.

> Now, that's a target I'm not too interested in, because I'm an
> application developer, not a "web site" developer.
> But that's just me, indeed.
I expect to be talking to the framework developer part of you right now :-)



More information about the Cubicweb mailing list