Re: password cookie

I think that´s not exactly what i´m looking for.

Just to make sure that i understand what you´re proposing (please correct me
if i´m wrong):
I´ll write a function that will create a hash of username, password and, say
'now'::timestamp and store it in a cookie and in a separate table somewhere
on the cluster, if authentication is succesfull.
Then, upon every need for authorisation, the frontend will log into the
database as a highly priviliged user (or allready be logged in), and compare
the hashed values. If they are equal, it will allow certain actions.
After some time, i´ll trigger to delete the hash from the database.
I could still store the user name on the back end, and retreive it with the
provided hash, so that i know what actions to allow. I would then fake
postgreSQL´s authentication by querying the rights and roles for this user.

The problem is that the frontend would in fact have to be some major user
that regulates all authorisation, and the password for it would have to be
stored on the webserver.

What i am looking for is this:
Every time the user / frontend asks for certain data (or actions), he will
or will not receive those, because of the rights granted to him. These
granted rights and roles will be determined by the regular postgres
functionality (and some views).
The frontend does have a low priviliged username and password stored in it,
just to access the web-content.

WBL

On 10/25/06, Andrew Sullivan <ajs(at)crankycanuck(dot)ca> wrote:
>
> The usual workaround I'm familiar with is to set a hash of some sort
> that is the user, password, and some salt. Then you authenticate
> against that hash in your application, so that you never actually
> send these values, nor store them anywhere except the database.
>