[Cubicweb] Pyramid & Cubicweb sessions/authentication integration
Christophe de Vienne
christophe at unlish.com
Mon Jul 7 15:57:56 CEST 2014
The thread having a lot of leaves, I will summarize my point and target :
I think the session.DATA of cubicweb needs not to be a repository concept.
It belong to the "web" layer, or could be say the "application" layer.
If, in some cases, some chosen datas needs to be made available to
hooks, having connection-bounded data is enough.
This would allow, if we switch the web layer of cubicweb to a pyramid
based one, to use the session API of pyramid, thus make use of the
numerous backends that implement it.
As for not mistaking web session data and repo session data, it seems to
me that repo session data is unnecessary.
And, to be clear, I am not looking for extreme flexibility. All I want
is to place the right concept in the right place so that we can make use
of the pyramid ecosystem, while not having too much web-related things
in the shell script (ie the repo) api.
So I definitely includes the "application developer" in my vision.
I hope it clarifies my goal.
Le 07/07/2014 15:27, Aurélien Campéas a écrit :
> On 07/07/2014 15:09, Christophe de Vienne wrote:
>> 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
>>> 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.
> Why ?
> Let's dig all the untold assumptions lurking around :)
>>>> - 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.
>> Letting the hooks access the web app context (ie the web request) in
>> some cases where it is needed is a different matter.
> Ok, let's not talk about it.
>> What bothers me is imposing a session data system that is shared between
>> the repository and the webapp.
> Why ?
>> The (web)application should be able to use any session data system.
> Looks like you are asking for some kind of extreme flexibility
> which is a .... problem in itself. I'm basically against
> any kind of flexibility until you can prove you absolutely
> need it :)
> Because, YAGNI.
> Now, that's only tengential to our discussion I believe.
>>>> 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.
> You mean, the session.DATA concept ?
>>>>>>> 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.
> I'd better not let the user choose anything if possible.
> Python philosophy "One Obious Way To Do It".
>> And yes I would like to use sessions not provided by the cubicweb repo.
> Please expand. I can't imagine why you would want that.
> I suspect we will soon talk about a session "interface".
> We *need* to clarify the session concept. You have something in mind
> and I may have something different.
>>> 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 :-)
> The framework developper in me is *never* divorced from the app
> developer. When it comes to the "web", I'm only interested in it
> as the modern medium to which one builds an application user
> Lacking experience in the web-site side of things might be
> a hindrance, or at least limit my empathy towards your goals.
> I probably will continue to fail to see what you are leaning to
> unless you make your preoccupations (and relevant philosophical bits)
> much more explicit ...
> Cubicweb mailing list
> Cubicweb at lists.cubicweb.org
More information about the Cubicweb