[Cubicweb] Pyramid & Cubicweb sessions/authentication integration
aurelien.campeas at logilab.fr
Mon Jul 7 13:02:23 CEST 2014
On 07/07/2014 12:44, Christophe de Vienne wrote:
>>>> What do you mean by strong bind ?
>>> I mean the obligation that a repo session lives from the web user login
>>> to its logout.
>> If by "living" you mean the python object is kept in memory, then not.
>> If not, then, what ?
> I mean having a unique ID associated with an identity and some datas.
>>>> If the cubes expect session.data to be there, it's strong... not ?
>>> Do they expect the .data to live all along the web-session ?
>> Yes. Note that there is no really a web-session as opposed to a
> Not in the current cubicweb, but I think it is the right moment to
> discuss this point.
>>> And if they do, isn't it because they rely on the repo session to hold
>>> data that should belong to the web session ?
>> 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
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.
> - 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
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.
> 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.
>>>> 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.
Something like: we want sessions, but NOT provided by the cubicweb repo.
(e.g. we make a mostly non-database app with cubicweb).
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.
More information about the Cubicweb