Files
@ 70e29dc91deb
Branch filter:
Location: kallithea/CONTRIBUTORS - annotation
70e29dc91deb
2.1 KiB
text/plain
ini file: clarify that beaker.session.key should be unique
When several instances of Kallithea are running on the same machine, the
same browser cannot be logged into both instances at the same time without
conflicts. The login session are saved into the same cookie; logging into
one instance closes the session on the second instance and vice-versa.
This is caused because the cookie name is simply 'kallithea', combined with
the fact that the cookie specification (RFC6265) states that there is no
isolation of cookies based on port. This means that the browser sends all
cookies from a given domain with all services (Kallithea instances) running
on that domain, irrespective of port.
The services thus need to handle any such issue themselves, for example by
using unique cookie names and only interacting with one's own cookie.
Making the key unique when creating the configuration file proved difficult:
- it does not seem possible to hook into 'paster make-config'
- since Beaker directly interprets the beaker.session.key, changing it on
the fly from SessionMiddleware will not work correctly.
There is a kallithea-config script that is an alternative to 'paster
make-config' which would be the ideal place to make such changes. However,
it seems this method is not advocated over 'paster make-config' (yet?).
Instead, simply add a comment in the config file and let the user take care
of it.
When several instances of Kallithea are running on the same machine, the
same browser cannot be logged into both instances at the same time without
conflicts. The login session are saved into the same cookie; logging into
one instance closes the session on the second instance and vice-versa.
This is caused because the cookie name is simply 'kallithea', combined with
the fact that the cookie specification (RFC6265) states that there is no
isolation of cookies based on port. This means that the browser sends all
cookies from a given domain with all services (Kallithea instances) running
on that domain, irrespective of port.
The services thus need to handle any such issue themselves, for example by
using unique cookie names and only interacting with one's own cookie.
Making the key unique when creating the configuration file proved difficult:
- it does not seem possible to hook into 'paster make-config'
- since Beaker directly interprets the beaker.session.key, changing it on
the fly from SessionMiddleware will not work correctly.
There is a kallithea-config script that is an alternative to 'paster
make-config' which would be the ideal place to make such changes. However,
it seems this method is not advocated over 'paster make-config' (yet?).
Instead, simply add a comment in the config file and let the user take care
of it.
24c0d584ba86 79283d4b1bed 79283d4b1bed 79283d4b1bed 79283d4b1bed 3dbe675b4342 62c4027b0321 c3172bc09503 3dbe675b4342 3dedf3991d40 dc16211e7292 dc16211e7292 dc16211e7292 dc16211e7292 a7bee2a5de67 ee2817f2cb3d ee2817f2cb3d fb51a6fc10ae fb51a6fc10ae 3dbe675b4342 c4d8ed624728 9989d727ef1b 9989d727ef1b 31265f80cf8b 31265f80cf8b e61162c20222 02e668af87ac 02e668af87ac b1b31bfe2f99 b1b31bfe2f99 231160230379 c6f16271b60c 12b183c1628b 5f08551afb31 0c1c17db467c 53e5f01081ac c71e05076359 d8364b7e3451 433d6385b216 8b7294a804a0 8b7294a804a0 231160230379 8b7294a804a0 8b7294a804a0 9a6c224e1f68 8b7294a804a0 8b7294a804a0 231160230379 231160230379 231160230379 231160230379 231160230379 | List of contributors to Kallithea project:
Marcin Kuźmiński <marcin@python-works.com>
Lukasz Balcerzak <lukaszbalcerzak@gmail.com>
Jason Harris <jason@jasonfharris.com>
Thayne Harbaugh <thayne@fusionio.com>
cejones <>
Thomas Waldmann <tw-public@gmx.de>
Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
Dmitri Kuznetsov <>
Jared Bunting <jared.bunting@peachjean.com>
Steve Romanow <slestak989@gmail.com>
Augosto Hermann <augusto.herrmann@planejamento.gov.br>
Ankit Solanki <ankit.solanki@gmail.com>
Liad Shani <liadff@gmail.com>
Les Peabody <lpeabody@gmail.com>
Jonas Oberschweiber <jonas.oberschweiber@d-velop.de>
Matt Zuba <matt.zuba@goodwillaz.org>
Aras Pranckevicius <aras@unity3d.com>
Tony Bussieres <t.bussieres@gmail.com>
Erwin Kroon <e.kroon@smartmetersolutions.nl>
nansenat16 <nansenat16@null.tw>
Vincent Duvert <vincent@duvert.net>
Takumi IINO <trot.thunder@gmail.com>
Indra Talip <indra.talip@gmail.com>
James Rhodes <jrhodes@redpointsoftware.com.au>
Dominik Ruf <dominikruf@gmail.com>
xpol <xpolife@gmail.com>
Vincent Caron <vcaron@bearstech.com>
Zachary Auclair <zach101@gmail.com>
Stefan Engel <mail@engel-stefan.de>
Andrew Shadura <andrew@shadura.me>
Raoul Thill <raoul.thill@gmail.com>
Philip Jameson <philip.j@hostdime.com>
Mads Kiilerich <madski@unity3d.com>
Dan Sheridan <djs@adelard.com>
Dennis Brakhane <brakhane@googlemail.com>
Simon Lopez <simon.lopez@slopez.org>
Jonathan Sternberg <jonathansternberg@gmail.com>
Grzegorz Rożniecki <xaerxess@gmail.com>
Andrew Kesterson <andrew@aklabs.net>
David A. Sjøen <david.sjoen@westcon.no>
Jelmer Vernooij <jelmer@samba.org>
larikale
SteveCohen
RhodeCode GmbH
Sebastian Kreutzberger <sebastian@rhodecode.com>
thomas <thomas@rhodecode.com>
Bradley M. Kuhn <bkuhn@sfconservancy.org>
Sean Farley <sean.michael.farley@gmail.com>
Martin Vium <martinv@unity3d.com>
Daniel Anderson <daniel@dattrix.com>
Travis Burtrum <android@moparisthebest.com>
|