Oh, okay. Well, just how ignorant are you, Mark? There comes a point where the only way to be clearer is to just write the code....
You've got the registration form written up. I'll assume that the username field is named "username" in the HTML, the password is "password", and the submit buttin is named "submitlogin".
An obvious first thing is that the form use the POST method - otherwise username and password get displayed in the URL and that is not a Good Thing.
There are all sorts of ways of proceeding from here. Here's one.
Have the registration form named "login.php", and have the form submit to itself (login.php).
At the top of the page, start <?php and check to see if isset($POST['submitlogin']). If it is, then we've got a login attempt to process.
Have a look at $_POST['username'] and $POST['password']. If they're both set as well, we can proceed further, otherwise, the form was incomplete, and we set $error_message to something suitable.
For convenience, let's now set $username=$_POST['username'] and $password=$POST['password'].
Build a SELECT query that returns a count of the number of rows WHERE username='$username' and password='$password'.
Run the query, and see if the result is at least 1.
If it is, use header("Location: main.php") so that the person who's just logged in goes to the main page, and call exit().
If they're still with us, it means either that their login attempt failed, or they haven't even tried yet (this is the first time they saw the page). We can distinguish the cases by whether or not $_POST['submitlogin'] is set. If it is, set $error_message appropriately.
Redisplay the login form. If $error_message is set, write it somewhere on the page so's they know why they're still looking at a login screen instead of the main page.
I've completely skipped over a couple of points. First, it's generally considered a good idea to store the passwords in the database in an encrypted form by using md5($password) (or md5(md5($password)) if you feel like it), for example. Store the encrypted version of the password, and encrypt the password that the user submits the same way before testing it against what's in the database.
Also, it's a good idea to make sure that $username has a sensible value that "looks like" a proper username (with the password encrypted, there's no need to check that); without this check someone could enter something that turns the database query into custard.
Third is making sure that people stay logged in while they're going through the site, and also so that people can't just bookmark or link to the main page and subsequently then hit it directly. One way to do this is to use session variables:
If they successfully logged in, set $SESSION['logged']=true and maybe $SESSION['username']=$username just before using header().
On each page that requires users to be logged in, the first thing you do is look to see if $SESSION['logged'] is set and true; $SESSION['username'] can be used to personalise the page for that user. If either or both are missing, then set make both session variables =null, call header('login.php'), and exit().
If they're still with us, then we're happy to go on and display the page.
The database; a users table of course, with a unique numeric id (you never know when you might need one), a username (also unique), an (encrypted) password, and maybe some other stuff relevant to the user.
An extremely simple login system is straightforward enough to do, but it does take a bit of thinking to do one right. There are all sorts of things that can be done to elaborate. E.g., you might want to set a cookie on the visitor's browser that PHP uses to log them in automatically when they go to the site (login.php would look for this cookie, and if it's valid, redirect them to main.php without ever bothering to display the form).
Registration is more elaborate; it could just be a simple form that collects stuff and puts a new record into the database (check the submitted data first to make sure no-one's trying to break anything); have them enter the password twice ('cos they can't see it) and make sure they enter it the same way each time. Processing is much the same as for logging in: submitting to itself, seeing whether this is a registration attempt or not, testing the data's consistency if it is and either inserting it into the database or generating an error message and redisplaying the registration form. If the registration was succesful, you could direct them to login.php.
Anyway, all that's off the top of my head. I know there are holes in it, but to plug them properly would require a pretty solid article on user registration and authentication, and there's already one of those on this site.
