Question

I'm a newbie to all things web programming and I have decided to start out with PHP/MySql/Apache, avoiding frameworks to keep things as simple as possible.

My project will involve my db holding personal data for clients so security is a priority, (although non-financial). Therefore I've been researching secure logins, beside my front landing page, everything else will function behind an ssl login.

My background is in oracle and I have developed solutions in oracle forms, where each user would get a db login and users were authenticated against such, whereas as with MySql/PHP, authentication seems to be modelled so that you connect to the db with a generic username/password and then authenticate against a users table with a hashed password.

I have always found the user session variable in oracle very useful, (select user from dual), be it for controlling access to tables, packages, triggers, audit logs, managing sessions, etc.

My question is, why isn't user management carried out like this on a web (MySQL) application? Am I harking back to client server days and would I be incorrect to model it this way, be it for scalability, security reasons etc?

All discussion and examples point to the users table model, the only detail I found on db authentication was here.

No correct solution

OTHER TIPS

Having come from an Oracle background (6 years Forms + Reports + PL/SQL) into PHP (the last 10 years) I feel as though I should empathise - but I don't! This is mainly because I never understood why anyone would want to mirror application users as schemas in the database.

The big difference, I think, is that the database is generally regarded in the web development world a base for storing data. In the Oracle world the database is seen as the centre of the application architecture.

If you view user access, their rights and privileges as just data, then it starts to make sense that the business of evaluating the rights and privileges and acting accordingly is the role of the application. This is contrary to the Oracle view that the architecture itself should deal with it.

A huge advantage of managing the users as data yourself is the flexibility it affords you.

For example, what if you wanted a multi-tenanted application (paid for service, multiple business, all accessing the same database instance, but with data split so that each can't see the other's).

In the Oracle world you describe you would only be allowed to have one instance of a given username across the whole of your offering - I.E. between businesses. This sounds unmanageable.

And what if you wanted to allow usernames with spaces in them? Or use their e-mail address? You need to start applying some form of translation.

In my opinion, managing it yourself simply gives you more flexibility, and would be my default position.

I am not seeing any pro's to support the use of DB user accounts instead of considering a users table :

In my opinion it would be easier to have say a billion users as rows in users table rather than to have a billion database user accounts .

If you have hundreds of different user-rights , I think either way you would need a user_rights table anyway . In which case why not have a users table as well ?

Considering you would not have separate set of data tables for each user , I think all the users would need to have access rights to all the data tables anyway .

The scripts that manage users through your online application ( say adding new users , setting user rights , etc . ) , I suppose would need to have some sort of root level access . If any of these scripts could be compromised , your whole application would compromised anyway .

As Rob Baillie has already mentioned , you would be restricted to the username naming convention of the database you choose . Considering it might not be practical , you would need some sort of translation to overcome this .

There are a few reasons I can think of - the primary being that the user data is specific to your application, not the database. The users don't need permissions/access or anything else for the db, so why set them up there?

Secondly, you have full control over how you store and manage your user data with your application if you don't store them as db users. You're free to employ whatever method, standard or style of development you wish to.

Thirdly, security - you really don't want to have your users connected in any way directly to your database. One slip up during the development could mean they have some way to log in to the db directly.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top