[Cubicweb] Pyramid & Cubicweb sessions/authentication integration

Christophe de Vienne christophe at unlish.com
Mon Jul 7 12:44:32 CEST 2014


Le 07/07/2014 12:12, Aurélien Campéas a écrit :
> On 07/07/2014 12:06, Christophe de Vienne wrote:
>> Le 07/07/2014 11:51, Aurélien Campéas a écrit :
>>> On 07/07/2014 11:43, Christophe de Vienne wrote:
>>>> Le 07/07/2014 11:13, Aurélien Campéas a écrit :
>>>>> On 07/07/2014 11:02, Christophe de Vienne wrote:
>>>>>> You are right, it is not cw sessions that are persistents, but the web
>>>>>> sessions and identity of the user.
>>>>>> A cw session is regenerated when needed.
>>>>>>
>>>>>> That said, I came to wonder what is the actual scope of a cubicweb session.
>>>>>> For what I understand, it holds the identity of a user, and can provide
>>>>>> connections to the repo.
>>>>> As of the top end of the persistent sessions stack, it is that,
>>>>> plus `.data`.
>>>>>
>>>>>> If it is only that, then we could, if not get rid of them, at least
>>>>>> consider them only as an identity cache that is renewable on-demand and
>>>>>> does not need to be bound to the web-session.
>>>>>>
>>>>>> But I sense it is a little more because of the session-data. The thing I
>>>>>> don't know is how these session-data are used and how much do they
>>>>>> really need to be strongly bounded to the web-session.
>>>>> They are not massively used but are clearly needed.
>>>> The need for cw persistent sessions looks needed, but for now I fail to
>>>> see real-life example where a strong bind to the web-session is required.
>>>>
>>> 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.

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


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


Regards,

Christophe



More information about the Cubicweb mailing list