Re: [GENERAL] password cookie
I just learned to read, sorry.You mean not to do the second thing, which i do want to do (where each frontend user equals a database user).Thank you for your advise.I´m not sure if i can get around it, but i´ll use extra caution anayway. WBLOn 10/27/06, Willy-Bas Loos [EMAIL PROTECTED] wrote: My suggestion is don't do that. I tried to do it once, years ago, and regretted it deeply.Do you mean don´t try to fake postgres´ authorisation (which i don´t want to), or don´t set up your webservice so that users will recieve data according to their own rights in the database, where each frontend user equals a database user (which i do want to)? WBL
Re: [GENERAL] password cookie
On Thu, Oct 26, 2006 at 12:27:49AM +0200, Willy-Bas Loos wrote: 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). Ah, that's a different matter. My suggestion is don't do that. I tried to do it once, years ago, and regretted it deeply. Of course, my code was awful, and yours might be better. But in my view, that's a security problem just waiting to happen. You're better off to have one user in your application that does the authentication for you. You can use Kerberos or something to authenticate it; much easier to lock down one such user carefully, that comes only from boxes under your control, than to secure many users' accounts. If you want to do it this way, I sure wouldn't use cookies to store the password. I think you're asking for a compromise that way. A -- Andrew Sullivan | [EMAIL PROTECTED] The fact that technology doesn't work is no bar to success in the marketplace. --Philip Greenspun ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
[GENERAL] password cookie
Hi,I´m envolved in developping a website that will function as a frontend for psql 8.1 cluster.We use a number of frontend technologies, and we want to keep the authentication in the backend. Not a system where the frontend queries a table to verify username password, sets the priviliges on the front end and logs in as a superuser on the backend. So we need to have username and password ready at a lot of moments, too many for a user to type it in all the time. Since we´re on a very tight time schema, we don´t want to implemt LDAP just yet, since it will complicate things (even) more. Especially synchronising user (role) changes between PostgreSQL and the LDAP server seems tricky, since the database cluster stills keeps its pg_authid tables (right?). So as a temporary compromise, we decided to store the username and password in a cookie on the client PC, which is of course a serious weakness.Can anyone give me some advise on how to do this a better way, without consuming too much time, or is this the best thing to do in such a situation?
Re: [GENERAL] 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.WBLOn 10/25/06, Andrew Sullivan [EMAIL PROTECTED] 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 authenticateagainst that hash in your application, so that you never actuallysend these values, nor store them anywhere except the database.
