Here is the current situation: I have a login page on which user enters his username and pass. Then I connect to the database using a “hardcoded” user (in the script), which opens connection to the server and executes the query to check if this data that user submitted is valid, and if so it “recognizes” him as logged in. This is the scenario that I saw and used in most of my applications.
Now, since I already have a database with many users (postgres database roles and not table “users” – I have to stress this to not mislead you) I was wondering if it would be good practice to do a pg_connect with a username and password the user puts in the login page.
My further question is how would I then keep them logged in? Session variable with username and hashed password? How is this affected from security viewpoint?
I would be grateful for your answers and any good reading material is appreciated!
I don’t think that’s wise at all. Technically you would have your root or admin user which can DROP or ALTER tables right? You don’t want it at all possible for a user to get access to your database internals.
Why don’t you have a separate table (at the moment that is)? If you require your users to have real database access (for another system or application) then you should still create a proper users table.
You can always write a script which will sync the data across from the internal DB users table to your application users table.