From: Eric Hodel <drbrain@...7.net>
Date: 2004-05-08T01:13:58-07:00
Subject: Re: What is Borges?

--Ios1FkwfffwWp4ib
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Carl Youngblood (carl@youngbloods.org) wrote:

> Forgive me for keeping this on the main ruby list and not on Borges, but=
=20
> I would like to get input from other web programmers who may not be=20
> using Borges.
>=20
> Kaspar Schiess wrote:
>=20
> >| - Does the sessioning stuff support automatic fallback to GET-based
> >| session ID propagation if the user has disabled cookies?
> >
> >    You must use URL based session id's, there is no way around it.=20
> >You can
> >optionally have cookies on top of that, but the urls really must be
> >there because of how Borges/Seaside is designed. And this probably does
> >not bother you anyway, since Borges should only be used for
> >Applications, not for Web Publishing.
>=20
> You are probably aware of this, but putting session IDs in URLs can make=
=20
> it easier to hijack sessions.  Here is a good article that explains some=
=20
> of the things to consider when designing a session manager (it's for PHP=
=20
> but the principles are universal):=20
> http://www.sitepoint.com/blog-post-view.php?id=3D156260&ct=3D1

You could put the session ID in a cookie, but the action ID must stay
in the URL (the action ID holds where in the API a page exists).

> Particularly, it is important to make sure that any external links don't=
=20
> get the session appended to them, or other internet servers will see them.

Sessions stay active for up to 5 minutes after last access by default,
reducing the window of hijackability.

> >| - Can sessions be stored in a database or a drb store so that web
> >| traffic can be easily load-balanced across multiple web servers?
> >
> >    One session should always use one server. This is because server=20
> >state
> >is not saved, but kept alive in a Ruby process on the server. Ruby can't
> >currently dump what would be neccessary to dump to be able to save off
> >to a database (mainly continuations...).
> >    Load balancing can balance sessions (users) to different backends,=
=20
> >from
> >different frontends. But one session is always handled by one and the
> >same backend.=20
>=20
> The advantage of using another backend for sessioning is that a=20
> webserver can fail or be rebooted/replaced without any users being=20
> affected by it.  They will transparently be sent to a different=20
> webserver by the hardware load balancer and their session will remain=20
> intact.

While you could save and restore session data, you cannot restore the
state, because both Proc and Continuation are undumpable.

--=20
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04


--Ios1FkwfffwWp4ib
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFAnJbGMypVHHlsnwQRAueBAKD3XvOudeKDtrkAwKm94gW/LOTJnwCg9qD9
99qd1aexmXD11WoU+gL30wU=
=KivY
-----END PGP SIGNATURE-----

--Ios1FkwfffwWp4ib--