[Cubicweb] Pyramid & Cubicweb sessions/authentication integration
Christophe de Vienne
christophe at unlish.com
Mon Jul 7 12:06:56 CEST 2014
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 the cubes expect session.data to be there, it's strong... not ?
Do they expect the .data to live all along the web-session ?
And if they do, isn't it because they rely on the repo session to hold
data that should belong to the web session ?
> 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
More information about the Cubicweb