Thread: Managing users
Dear All, Forgive me if this is a silly question, but I need some advice. I'm setting up a db where users will be able to insert, update, select. I will have three types of users. Lowest can do very little, highest to do everything. I'm thinking of creating three groups (Level1 to Level3) for the 3 types of users. Is this the best way of doing this? If a user logs on, say through a web interface, would I have a table with username/passwd to check the login to the database? Or should I somehow use the pg_user table? Also, is there a way of monitoring how much memory a user takes up. For example, I have a table username/Data. How much memory does each username take up on that table? Thanks for your time and help Colin _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger
Dear C G , > Forgive me if this is a silly question, but I need some advice. Forgiveness granted :-) > I'm thinking of creating three groups (Level1 to Level3) for the 3 > types of users. Is this the best way of doing this? Yes without doubt to my experience this is a better method > > If a user logs on, say through a web interface, would I have a table > with username/passwd to check the login to the database? Or should I > somehow use the pg_user table? Considering you are using PHP +PostgreSQL You can use the pg_user table Just you have to do is 1. Make two cookies variable each storing the password and user name 2. Now in the Database connection string use the user name as the var in Cookie and password same so it would be like pg_connect(blah , blah user name=$COOKIE_VAR_USERNAME , password =$COOKIE_VAR_PASSWORD) Benefits 1. You will be able to use current_user() function 2. No user management system required PostgreSQL user is ur web user 3. PostgreSQL group will define levels > > Also, is there a way of monitoring how much memory a user takes up. > For example, I have a table username/Data. How much memory does each > username take up on that table? I doubt but you may see contrib/database_size function If this helps then pass on the word "PostgreSQL is Walah !" and kindly shoot back Regards, V Kashyap
Dear C G , > Many thanks for your quick response and answer. It is very much > appreciated. I am honored :-\ > Can I ask two further questions? If I only allow connectinos to be made to the DB using hostSSL in the pg_hba.conf file, will that be sufficent in security terms? SSL sounds good but dont know with firm belif if it will be enough Regards, V Kashyap
I did this with the php_lib_login and the ADODB package. php_lib_login needs to be updated for current versions of php however it does have extensive functions for handling user logins. Tom On 5 Dec 2003 at 16:59, Sai Hertz And Control Systems wrote: > Dear C G , > > > Forgive me if this is a silly question, but I need some advice. > > Forgiveness granted :-) > > > I'm thinking of creating three groups (Level1 to Level3) for the 3 > > types of users. Is this the best way of doing this? > > Yes without doubt to my experience this is a better method > > > > > If a user logs on, say through a web interface, would I have a table > > with username/passwd to check the login to the database? Or should I > > somehow use the pg_user table? > > Considering you are using PHP +PostgreSQL > > You can use the pg_user table > Just you have to do is > 1. Make two cookies variable each storing the password and user name > 2. Now in the Database connection string use the user name as the var in > Cookie and password same so it would be like > pg_connect(blah , blah user name=$COOKIE_VAR_USERNAME , password > =$COOKIE_VAR_PASSWORD) > Benefits > 1. You will be able to use current_user() function > 2. No user management system required PostgreSQL user is ur web user > 3. PostgreSQL group will define levels > > > > > Also, is there a way of monitoring how much memory a user takes up. > > For example, I have a table username/Data. How much memory does each > > username take up on that table? > > I doubt but you may see > contrib/database_size function > > If this helps then pass on the word "PostgreSQL is Walah !" and kindly > shoot back > > Regards, > V Kashyap > > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match >