Hiya! , I'm currently working on a user login script at the moment, but I'm not sure what should happen when the user logs-in? How would the system keep a record of whether the user has already authenticated? Many Thanks, FishSword
Cookies or sessions. Buy a PHP book, they're so invaluable. You miss too much if you pick bits from the internet.
What should the session contain, and what should the session match with to allow the user to be logged. I have research on the internet that session id's can be easily changed if the site is being hosted on shared hosting. is there any way to prevent this. I have also found out that sessions can be hijacked. How do I prevent this?
If you're asking me those questions, you seriously are better off doing some good reading mate. You could use a database to store the time a user logged in and treat him as authenticated until he logs out, but that's very long winded and unnecessary. Just make sure identifying data is hashed (with MD5 or something). I'd use cookies if I were you. They're easier to handle and understand. For example, a user's cookie may contain their hashed username. When checked against a database, and if correct, the user is still authenticated. Never put passwords in cookies. As for sessions, I've never known for them to be hijacked, whatever that means. Sessions are stored server side and handled by PHP; slower than cookies but generally more secure.
If you really have no clue man (which it seems you don't, no offense, we all started somewhere) and you're not going to buy a book (which i highly recommend), then go Google PHP login scripts and find some tutorial sites which at least walk you through a basic login script setup. Then mix and match security techniques from other tutorials you find to make that script more secure. At the very base level of login security at least make sure you hash (with MD5 or SHA1) people's passwords!
Mysql, server side sessions, cookies, md5 hash protect passwords. Find a nice tut online about it. Then print out the tut on paper. Follow along as you type out each of the pages. login-form after-login page when they hit submit. register page where they type in the info after register page after they type in the info. will you be emailing them a validation code? you need mail code for that. validation page they get to when they click the link in the email. are you going to have a catcha on the login screen? are you going to have them be able to edit the profile stuff? you need the add, edit, delete pages of that if you are. then your going to need an user editor admin page. to edit, add, delete user data if you need too. also going to have to figure out if they are login'd in or out and then allow access to each of the pages according to that. You think you can do all of that?
Yes, all of that is fine, except the check login bit. As I have only created simple login scripts for myself, I have always used just the username as the check value. (Very insecure I know) but it was just to provide me with functionality to play around with adding more features to a project. Now however, I wish to carryout a proper stab at doing a login script, and therefore require a more secure method of storing the check value. The issue I have though, is that I also wish to track how many users are online, and am therefore extremely confused on how this is going to work. For inspiration, I have checked out some forum software (phpBB, myBB, and smf), and each of these store session data in a table call sessions. Is this the best/only way this can be done?
Of course not, I always use cookies that contain an MD5 hash of a username (or user id) then compare to db to check user exists. To track how many users are online, have a date and time stored when a user logs in and logs out, then simply check the time frame to determine how many are still online.
Do you not useful sessions yourself? Doesn't this make it more difficult when you want to display information on one page to another?
I've started to use sessions recently, but cookies are easier to program and manage. There's no difficulty between the two.
Cookies are more limited than sessions, but I wouldn't say they're for different purposes. Go to php.net and look up sessions and cookies, all the info. You need should be there.
They serve the same purpose, save user data in an stateless environment (i.e. HTTP) cookies are stored on user's computers, they are cross script accessible. e.g Set cookie in PHP, fetch them in javascript. Cookies can be set to exist even after user leaves the domain and can be fetched later, when he comes back. PHP server side sessions store data in server memory. They are not cross script accessible, you can access PHP sessions in PHP only in the same domain. Also unlike cookies, sessions are volatile, so when user leaves the site, session data is expired after the keep alive time and can not be accessed. Sessions are generally faster than cookies, because they are stored on server itself.. Sessions can only be hijacked if, either your user is a moron or you allow XSS (Cross Site Scripting, Google it if you think I'm speaking Latin) injections. You can't do anything about your user's stupidity except try and educate them, But you can prevent XSS by filtering all user input, stripping executable codes and tags etc and any unrecognized binary/bytecode data (Any data that is not Ascii or Unicode). Lastly as BRUm suggested, buy some PHP books, then buy some PHP security books, then buy some Cryptography books and read them all...