[Cubicweb] Pyramid & Cubicweb sessions/authentication integration

Aurélien Campéas 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
>> repo-session.
> 
> 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
> 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.

> 
> - 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.

> 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).

Right ?

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.

Regards,
Aurélien.




More information about the Cubicweb mailing list