Hi Bruno,
Am Montag, 22. Jan 2007, 23:11:41 -0600 schrieb Bruno Wolff III:
If the web server is running on the same machine as the DB,
then consider using ident authentication and connecting using domain sockets.
Ah, a good suggestion. Thanks!
I found an exhaustive documentation on
On Mon, 22 Jan 2007, Bruno Wolff III wrote:
On Mon, Jan 22, 2007 at 20:25:48 +0100,
Bertram Scharpf [EMAIL PROTECTED] wrote:
What I want to do is the following:
1. Login in from a program on a client as a particualar user.
For this case you shouldn't need to do anything tricky as
On Tue, Jan 23, 2007 at 09:44:28 +0100,
Bertram Scharpf [EMAIL PROTECTED] wrote:
Hi Bruno,
Am Montag, 22. Jan 2007, 23:11:41 -0600 schrieb Bruno Wolff III:
If the web server is running on the same machine as the DB,
then consider using ident authentication and connecting using domain
On Tue, Jan 23, 2007 at 09:01:56 -0800,
Richard Troy [EMAIL PROTECTED] wrote:
On Mon, 22 Jan 2007, Bruno Wolff III wrote:
On Mon, Jan 22, 2007 at 20:25:48 +0100,
Bertram Scharpf [EMAIL PROTECTED] wrote:
What I want to do is the following:
1. Login in from a program on a
On Sun, Jan 21, 2007 at 15:16:37 +0200,
Andrus [EMAIL PROTECTED] wrote:
No, the tables would be on the server, the same as was already being done.
Using a separate table makes it more future proof.
To access tables in server, you need to login into server.
To login into server, you need
Hi,
Am Montag, 22. Jan 2007, 10:25:33 -0600 schrieb Bruno Wolff III:
I didn't give an opinion on whether or not the whole approach was a good
idea or not, since there wasn't enough detail in the original question.
What I want to do is the following:
1. Login in from a program on a client as
No, the tables would be on the server, the same as was already being done.
Using a separate table makes it more future proof.
To access tables in server, you need to login into server.
To login into server, you need postresql user name and password sent by
client and thus stored in client
On Mon, Jan 22, 2007 at 20:25:48 +0100,
Bertram Scharpf [EMAIL PROTECTED] wrote:
What I want to do is the following:
1. Login in from a program on a client as a particualar user.
For this case you shouldn't need to do anything tricky as long as the user
is login in as themselves. Just
Hi,
looking at the source code I find out that this works:
sandbox=# create role joe login password 'verysecret';
CREATE ROLE
sandbox=# create function validate_user_8_1(text,text) returns boolean
immutable language 'sql' as $$ select 'md5'||md5($2||$1) = rolpassword from
pg_authid where
On Fri, Jan 19, 2007 at 09:31:49AM +0100, Bertram Scharpf wrote:
Hi,
looking at the source code I find out that this works:
snip
May I rely on this in future versions or are there more
sophisticated ways to do it?
Umm, how much more sophisticated do you want? It's more sophicticated
than
On Fri, Jan 19, 2007 at 09:31:49 +0100,
Bertram Scharpf [EMAIL PROTECTED] wrote:
Hi,
looking at the source code I find out that this works:
sandbox=# create role joe login password 'verysecret';
CREATE ROLE
sandbox=# create function validate_user_8_1(text,text) returns boolean
It might make more sense to use your own table of users and hashed
passwords
rather than postgres'. This would depend somewhat on the overlap of users
who
are using your application and those who connect directly to the database.
If there isn't much overlap, having a separate table is
On Fri, Jan 19, 2007 at 18:24:32 +0200,
Andrus [EMAIL PROTECTED] wrote:
It might make more sense to use your own table of users and hashed
passwords
rather than postgres'. This would depend somewhat on the overlap of users
who
are using your application and those who connect directly
13 matches
Mail list logo
