Forum Moderators: coopster
I have written a php user log on script which allows access to a home page for registered users whose user names/passwords are stored in the db. What I can't work out at the moment is a way to enable a script to only go to the users records, ie. the user that has logged on. Do I need to use sessions and how do I go between the user log on and then a unique db query?
Sticky me some code, and I'll take a look.
At this point, I stuff their uname into a session var and check for it on every secure page. If it's not there, send the visitor to the login page.
Lorax, thanks. I think I'm with you. I'm using php so if I return the query from the log-in script they must be a validated user name. If I start a session on each page this will check each time for the same user - is this correct?
How do I return the id of the last query? I'm not sure of the function to achieve that - much page turning going on!
I don't think that mySql supports foreign keys although I see what you are getting at.
Reminds me why I decided to switch to Postgres. MySQL is getting more feature-complete, but that's one I'd have a hard time designing a good data model without. You can do the same thing without telling the databse that the columns are foreign keys, but it's nice to have the referential integrity enforced by the database.
You can use 'select count(*) to verify they are valid:
$login_query = "Select count(*)
From admin
Where uname = '".$log_user."'
and pwd = '".$pwd."'";
$login = mysql_query($login_query);
$count = mysql_result($login, 0, 0);
if ($count > 0) {
$login_query = "Select *
From admin
Where uname = '".$log_user."'
and pwd = '".$pwd."'";
$login = mysql_query($login_query);
$user_details = mysql_fetch_array($login);
$log_user = $user_details["uname"];
$user_name = $user_details["name"];
session_register("log_user","user_name");
header("Location: admin/admin_home.php");
}
As for the checking part - at the very top of each page you need to begin with session_start() which will automatically refresh all session variables for use and immediately follow it with you check code.
Can you do that just for a select lorax? I know there is mysql_insert_id but that is for last inserted. At any rate you can just
select * from db where username="user" and password="pass" // where user and pass come from login form
if they get no data then they aren't in there and if they do then you have the id already.
Yes, no foreign keys is a pain but I still use them. You have to use them logically as opposed to physically but it works just as well.
There are a bunch of ways to store the user data cyclic. You could have directories on the site that are user specific. If they must be in the db then you could have seperate tables that have the username as the tablename. You could lump it all in one and use the user_id as the glue to associate everything together.
just a few thoughts
select * from db where username="user" and password="pass" // where user and pass come from login form
Rather than storing the password in the db, I generally store a cryptographic hash (md5 or the like) of it. That way, in the event that I screw up and there is some way to get my web site code to divulge data from the table with user data in it an attacker would still have to mount a dictionary attack on the passwords they found.
That doesn't do anything about sniffing, of course, and you'd have to either use https (what I do) or have some client-side scripting involved in the authentication (I've thought about it, and as soon as I have a text-mode browser with that much Ecmascript support I'll start doing it.) to protect against that. But it's one more obstacle to a cracker, and n easy one to implement. It's pretty much 2 calls to the md5() function in your scripting language. One on insert/update of passwords, and one on authentication of a password.
But now that you mentioned it - how much of a performance hit do you take when implementing encryption?
Most often though I use md5().
SSL I use less often, for two reasons. First, it's a bit of a hassle to set it up. Second, for most of the stuff I've done so far the cost of a certificate is prohibitive. I roll my own regularly, but browsers tend to complain about that, and your average user doesn't know enough about the operation of SSL to know what the warning means. I think users are in most cases going to feel better about an insecure site that doesn't trigger a warning from their browser than a secure one that does.
As for overhead in encryption, I really don't know how it stacks up. I tend to write *very* light-weight pages, and have a small enough user community right now that it hasn't been an issue. My guess would be that it works best if you have sticky visitors and use persistent connections, so as to avoid repeating the connection overhead, which is significantly higher for an encrypted connection than an unencrypted one. That's just a guess, though.
The people I am doing this for want the site hosted on SSL. This will be a first for me, does this give any particular problems and is it worth it? The data is sensitive but not not in monetary terms. I really don't think that ssl is justified but they have seen the "padlock" and think that is the answer to everything!
If security was highly important, there would of course be other things to worry about and the problem would be getting across to the client that the padlock has a very narrow meaning. If it'll make them happy, though, I don't see any harm in letting them have the padlock.
