[Grok-dev] Grok, sessions and authentication

[Souheil CHELFOUH]

It looks like, in most cases, it's not very wise to serve the static
resources via zope itself.
Exposing the needed files directly through apache, might work better,
avoiding the cookie latency problem, plus fiddling too much with the
session.
As a matter of fact, public resources requests could be intercepted at
the Paster level, with a middleware and served directly...

This is a very important subject, that I think concern many of us. it
would be interesting to write a little something on the Grok's website
about it.
There's a huge gap in Dolmen, regarding that matter. I'll try and come
up with real solutions and maybe write an article about it

2010/6/9 Jan-Jaap Driessen <jdriessen at thehealthagency.com>:
> On 9 June 2010 17:38, Jan-Wijbrand Kolman <janwijbrand at gmail.com> wrote:
>> On 6/9/10 17:04 PM, Souheil CHELFOUH wrote:
>>> Hello grokkers,
>>>
>>> I'm currently working on an users/groups system inside Dolmen and i'm
>>> fighting with the authentication and publishing process, to be able to
>>> allow certain URL to bypass the authentication.
>>> This is, obviously, for public resources retrieving.
>>>
>>> Digging into the zope-dev mail logs, I also found reports of problems
>>> i'm experiencing in Dolmen, involving read-write errors while
>>> accessing ZODB blobs.
>>>
>>> I get logs like :
>>> 2010-06-09 13:39:27,209 WARNING [ZopePublication] Competing
>>> writes/reads at SOMEURL: database conflict error (oid 0xfa, class
>>> dolmen.storage.container.OOBTreeStorage, serial this txn started with
>>> 0x0386b65fab734455 2010-06-09 10:39:40.183655, serial currently
>>> committed 0x0386b69b740d2a88 2010-06-09 11:39:27.199554)
>>>
>>> It seems it's linked to sessions. So, i'm launching a general buoy for
>>> the guys out there that have experience with zope3 and auth (Martijn,
>>> J-W ?). Can you give me some tips in these matters ?
>>
>> It is linked to sessions indeed. I'm not too experienced with ZODB blobs
>> to exactly know how these might interact in this case.
>>
>> Zope will try to get to the credentials stored in the session for each
>> and every request - including resources. Since there will be a lot of
>> requests close to eachother, read (and sometimes read/write) do occur in
>> our applications.
>>
>> These errors do not necessarily point out problems, it is merely the
>> ZODB conflict resolution at work there. If they occur very often though,
>> you will want to optimize the parts of your app that cause the conflict.
>>
>> We (at THA) intende to replace the session based storing of auth
>> credentials with a secure cookie-method. This would make - is the idea -
>> the hit on the sessions much less.
>>
>> Another strategy would be to not store the sessions anymore in the main
>> ZODB itself, but in a RAM based ZODB storage for example.
>>
>> This is quick response, there's much more to say on this topic... I hope
>> it is of any help though.
>>
>> regards, jw
>
> Another drawback of zope.pluggableauth's SessionCredentialsPlugin is
> that the password is stored in the ZODB in plain text. A secure cookie
> implementation such as found in beaker would solve this:
>
> http://wiki.pylonshq.com/display/beaker/Cookie-Only+Sessions
>
> --
> Jan-Jaap Driessen
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>