Re: Security fix that started all this

["Christopher Murtagh" <..hidden..>]

On 9/8/06, Tony Fraser <..hidden..> wrote:
> OK, so where do you plan to store the DB authentication information? Or
> do you plan to give every user their own DB account? Or do you plan to
> just have one DB account for all the companies in a installation?

 On central db for all users in an installation. Other than user
information, it will also store audit logs for successful logins and
attempts and other data that an admin of an installation might want to
track centrally.

> > - portability issues in dealing with filesystems (allowed chars, case,
> > etc..) are all gone
>
> That would be nice. But moving the info into the DB isn't necessarily
> the solution.

 It's not the only solution, but it's simple and comes with the very
little baggage. There are far more important things to worry about
than session handling, and since this is the easy method to implement,
document, support and keep secure, it's a no-brainer IMO. Do you have
any particular objections to this or are you thinking of a different
approach?

> > Also, we can move to a plugable authentication and support other
> > mechanisms (LDAP, Basic HTTP Auth, Kerberos, etc..) and store user
> > data in the db.
>
> The question still stands: Do we really want server side _per session_
> storage or was it just the way that seemed easiest to solve the problem at hand?

In the future the session handling will likely be more than simply
storing a session key. For example, with decent role management, etc,
the session would be a way to cache the users profile for their logged
in session so that it doesn't have to be queried/built for every page
load (1 simple select query followed by an explode/eval). Sure, this
can also be accomplished with /tmp files, but this brings up the
issues of the web server writing to the file system and portability
issues.

Cheers,

Chris