Jump to content

Database Login Credentials


Landslyde

Recommended Posts

When I first started this project, PHP was new to me and I didn't have a clue how to use it. Here, seven months later, I still don't know what I'm doing.

 

I have 47 pages that are MySQL intensive. Each client has their own login credentials to the database. I've been using the $_SESSION global to carry these credentials across the pages. I realize this is a huge security issue, but I don't know any other way to keep their username / password handy as they log in and out of the database. I've searched and not found anything resembling my need here. Most of the discussions relate to setting $_SESSION['foo'] = 'bar' and carying that from page to page.

 

I cld really use some insight on this. Thanks.

Link to comment
Share on other sites

:confused: I am hoping you mean credentials to the application as in a users table in the app DB, which if the case, $_SESSION is how you would do it although putting the password in a session is not what you would do.

 

You could do like

$_SESSION['login'] = 1;

And then on your pages check to to see if $_SESSION['login'] isset .

 

 

If you actually mean credentials for a Mysql connection  (Yikes! ) then you have some work to do.

(As in $con = mysqli_connect("localhost","my_user","my_password","my_db")

Edited by benanamen
  • Like 1
Link to comment
Share on other sites

Even if there was a sane way of keeping the database credentials in some kind of session, it's still an awful idea to let end users choose passwords for internal database roles. Many people routinely use passwords like “123456”, and you certainly don't want that as a database password.

 

End users are not database administrators (unless you're implementing some kind of PHPmyadmin), so it's your job to create an abstraction layer between the application users and the database roles. It does make sense to use separate roles for different user groups (e. g. standard users vs. administrators), but it's nonsensical to create a new role for each user.

  • Like 1
Link to comment
Share on other sites

Like I said, guys: I'm new to this. I get what you've all said. Even in the beginning I thought of doing it this way. But for some reason I got stuck on all the clients needing their own logins, and that made for a lot of extra work. It isn't all bad though, because I learned a whole lot in the process. And today, I learned a better way. I appreciate all of your comments. Thanks.

 

Time for a new pot of coffee so I can start untangling this mess I've made! :D

Link to comment
Share on other sites

You've been trying to pick up PHP for seven months and apparently haven't read a single thing on logging in and secure methods and good practices?  What HAVE you been doing for those seven months?

 

NEVER carry a password around.  You handle a password only for as long as it takes to get it from the user's entry into a login form and create a query to check the db. If the check passes you set a token that tells you who they are (user id?) and that they are logged in (as mentioned - $_SESSION['login'] = 1) or if necessary a token that gives you a value that translates to a security level if your appl requires that to be known.  Then you forget the password.  You'll not need it again.  And god forbid - you will not design your appl to 'help' the user by "remembering" his password.  Always make them signin, or at least set a cookie with a reasaonable duration if you must let them remain logged in for a certain window of time.

 

As for a db login.  Store the credentials (user id and password) in a mini php module that is stored outside of your web-accessible tree (I assume you know what that is) and reference that in your standard MySQL connection code (which I also assume that you have)  The uid/password is stored in only ONE place this way and not accessible by any of your users - only your php scripts.

 

After seven months you might want to pick up the learning pace and do some research to educate yourself on these elementary things.  :)

Edited by ginerjm
Link to comment
Share on other sites

Each of the clients has a memberID, and their clients are associated to them by this memberID. In whittling down the code and removing the username and password session vars, is it a risk to tie their memberIDs to a session var? It's either that or have them log in at every query. So is using a memberID session var a damaging approach?

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.