On Thu, Nov 22, 2001 at 11:26:59AM -0800, Tavis Rudd wrote: > > As can be guessed from what I've just written, it makes sense to > > "extend" sessions to allow a user identity to be associated with > > them. But no more than that should be involved; certainly not what > > rights someone has. > > Totally agreed. Someone's 'rights' should not be stored using > sessions. Although that's really up to the implementor of a > particular 'rights management' system.
However, you are both right. "Rights" are semi-permanent information which belong in a User or Userrights object. The session only needs a user identifier. Of course, with Basic Authentication the user ID doesn't even need to be stored in the session, but Basic Authentication has its own tradeoffs (not being able to log out, not being able to re-log in as someone else). > > The fact that WebKit only supports > > cookies as a session identifier "transport" is potentially a > > worrying enough factor demonstrating weaknesses in terms of > > accessibility. No, it just demonstrates the immaturity of the current implementation. What would be worrying is if Webware were stagnant. But it's not: the need for non-cookie Session IDs and seamless switching has been discussed several times, and steps have been taken in that direction, most concretely, the path prefix Session ID patch. I and others have proposed porting PHP's seamless GET/cookie Session ID switching to Webware, although it's been postponed because of the amount of design work required. But the point is, work is progressing in this field, even if it happens intermittently coz it's not ppl's highest priority. -- -Mike (Iron) Orr, [EMAIL PROTECTED] (if mail problems: [EMAIL PROTECTED]) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
