Help with user login

Reiji · 04-04-2008, 12:43 PM

Hello,

I am creating a user system and have no problems with the validation/registration...where I really have some problems is with the login part...the site i'm planing will make users stay a looooong time connected to the site and I don't know if it's better to use sessions or cookies (and I don't know how to use them either)...

Can someone please guide me in how can I make the user login part?

Thanks.

johnN · 04-04-2008, 12:50 PM

Basically php will use cookies whenever possible for sessions. Without cookies sessions can only be parsed via url which means you loose the session when you navigate away from the site.

When you check the "remember me" button on a site, it normally places a cookie which can then be retrieved. You can set the length a cookie lasts which is handy, but the user may have them turned off, or may clear their cookies prematurely.

Reiji · 04-04-2008, 01:02 PM

So I may basically make it with sessions unless the user choose the remember me option?

TerrorRonin · 04-04-2008, 03:48 PM

The cookie would basically just be a method of storing their username and password for future use. The login should just operate on sessions.

example:

<input username>
<input password>
<checkbox remember me>

Those would just be blank, unless they previously checked remember me. Then the cookie would auto-fill those forms.

The login wouldn't be changed though, if you have a session based login. A lot of people have cookie based logins, but I prefer session strict myself.

PHP: session_start - Manual

Village Idiot · 04-04-2008, 04:01 PM

Cookies are a fine way of storing login data. They are just as secure if the proper precautions are taken (as must be done with sessions). The general way I do it is this.

Cookie id
[The users ID]

Cookie pass
[The users pass]

At every page where it displays data you should be logged in to see, I have a function verify that ID and password in the database. If they match, the user is logged in. If they do not match, the user is given an error message.

Also, NEVER have the members username as the validating data, it could cause problems if there are more then one users by that name. Find the user by their unique ID.

Wildhoney · 04-04-2008, 09:01 PM

I wouldn't recommend storing the username and password because of cookie sniffing. However, if you're wanting to go down that route then store the session ID. Although session IDs are still susceptible to cookie sniffing, you can try your best to make it much more difficult to takeover a session that isn't yours. This is done by creating a fingerprint based on data you KNOW exists, such as the IP address. You can also add in optional parameters such as the user agent.

I have wrote us a basic class for the very purpose of resuming sessions. The cookie remains active for only an hour in this example, and so if a user doesn't login for an hour then the cookie will expire. It can be used like so:

php Code:

$pCookie = TalkPHP_Cookie::restore();

if(TalkPHP_Cookie::restore())
{
    session_id($pCookie->session_id);
    printf('Welcome back, %s', $_SESSION['username']);
}
else
{
    $_SESSION['username'] = 'Wildhoney';
    TalkPHP_Cookie::save();
    printf('Welcome, %s', $_SESSION['username']);
}

You should be able to close your browser and then return to the page. The class should pick up on the attempt to restore the session, and as long as your IP address matches the saved IP address, it will do just that.

I've not put the class through any rigorous tests. That's entirely up to you if you decide to use it

! It should say "Welcome back, Wildhoney" once the session has been restored. You won't want to restore the session on every page click and so that's where your own function would come in, to see if the user is already logged in or not.

php Code:

class TalkPHP_Cookie
{
    const COOKIE_NAME = 'talkphp_cookie';
    
    public static function save(array $aData = array())
    {
        @session_start();
        
        $aData['session_id'] = session_id();
        $aData['fingerprint'] = md5($_SERVER['REMOTE_ADDR']);
        
        setcookie(self::COOKIE_NAME, serialize($aData), time() + 3600, '/');
    }
    
    public static function restore()
    {
        @session_start();
        
        if(isset($_COOKIE[self::COOKIE_NAME]))
        {
            $szData = $_COOKIE[self::COOKIE_NAME];
            $pCookie = (object) @unserialize($szData);
            
            if(!$pCookie)
            {
                return false;
            }
            
            if(!isset($pCookie->fingerprint) || !isset($pCookie->session_id))
            {
                return false;
            }
            
            if(md5($_SERVER['REMOTE_ADDR']) != $pCookie->fingerprint)
            {
                return false;
            }
            
            return $pCookie;
        }
        
        return false;
    }
}

Reiji · 04-04-2008, 09:11 PM

Thank you everybody...I will try and process all that information :D

And Wildhoney, as I'm just starting with classes and OOP, I'll have to read that class of yours very carefully so I can understand what does every part of it means.

I'll let you all know how it went and copy some of the code in case you guys want to make me some corrections.

Thanks again and talk to you soon.

Village Idiot · 04-04-2008, 09:25 PM

I should add that while vB also uses sessions, if you look in your cookies, your user ID and encrypted pass are in there. With those two you can effectively change your account (I've done it, see Programming Tips Blog Archive The Danger of JavaScript Links in vBulletin and other forums). That is the one thing I dont like about cookies.

delayedinsanity · 04-04-2008, 11:24 PM

Well then. I have two edumacational questions regarding your coding style there Wildhoney, but in attempting to edumacate myself prior to asking them I seem to have broken my test server.

That's not good.

All I was trying to do was turn error reporting on in PHP so that I could tell if it was generating warnings or other notices when I accessed a class method without the class being instantiated. From the PHP manual,

Declaring class members or methods as static makes them accessible without needing an instantiation of the class.

Now forgive me if I've misunderstood this, but it would seem to call a method (someClass::method()) according to this you would need it declared as static. However, in writing some quick test.php code (my favorite file, I think there's one in almost every directory of my document tree) to see how a child class interacts with the parent, and visa versa, I had written some code in there which accessed methods and constants from my test classes previous to the class being called into existence.

I'm assuming however that since none of them were declared static, this is probably producing warnings, as it does not halt execution. So I went to turn my error reporting on, and apache won't restart when I have it set to on, but it will if I set it to off. Wtf. *kicks it*

Anywho, while I try to figure that out, I was also curious why you suppressed errors from calling session_start(). Does this sometimes have unexpected behavior?
-m

Wildhoney · 04-04-2008, 11:49 PM

They should be declared static if you're accessing them like so, yes. I will wait until you've further tested that, however, before we go any further so we remain on the same page.

As for suppressing warnings of session_start, I do this because of the following addition:

Quote:

As of now, calling session_start() while the session has already been started will result in an error of level E_NOTICE. Also, the second session start will simply be ignored.

Thus suppressing it will ensure no notice is shown, but will nevertheless guarantee that a session is started. However, with that said, programmers should really be ensuring it is started themselves, and so those 2 error suppressing lines -- 1 in each function, should be removed when in the capable hands of a competent programmer.

delayedinsanity · 04-05-2008, 12:45 AM

There we go, I got my error reporting on. I just have to restart apache twice when I switch php.ini settings for some reason.

Strict Standards: Non-static method testClass::testing() should not be called statically

So it allows it, but it doesn't like it. Coming from a non-object orientated background, I don't fully understand everything I'm doing just yet, primarily I just really like the flow and organization of using PHP's oop so I'm learning as I go. The best (short) explanation of static I found in the past hour was from Developer.com: An EarthWeb site:

Quote:

Most applications make use of various functions of use throughout the entire application. Because such functions aren't necessarily related to any particular object, they're often placed in a general utility class. However, such a strategy is followed because it's good OO programming practice, and not because we want to invoke a "utility" object (although you could). Rather, we just want to call the method as necessary, while still managing to encapsulate it in some sort of class. Class methods that can be called without first instantiating an object are known as static.

This and a few pages back and forward from it have helped clarify a few matters.
-m

delayedinsanity · 04-05-2008, 01:02 AM

So it would seem you can call a method statically, if it's not declared static, and it produces a warning, as posted above. However, if you declared the method static, and then call it regularily (with ->) it doesn't?