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@crankycanuck.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.
