Why? I want to make a login script, but I'm not sure if I should make it with PHP. What are the advantages/disadvantages? Thanks!

Advantage/Disadvantages making a login script in PHP? All are the same. With php you can use session_register() and $_SESSION variables to authenticate.

http://us3.php.net/session_register

PHP has quite possibly the worst OOP implementation of any language. That being said, there is not much reason to use any advanced OOP methodologies in a login script.

PHP has quite possibly the worst OOP implementation of any language. That being said, there is not much reason to use any advanced OOP methodologies in a login script.

Right. But I'm glad PHP does have a few oop features. Some of the developers/documenters of the PHP language realize it isn't very object oriented, but others apparently (and mistakenly) think it is. Here are two excerpts from the PHP manual. In the first quote, I'm not sure how they can say what they say when PHP supports neither function overloading nor polymorphism, among other things:

"PHP 5 fixes the OOP related weaknesses of PHP 4, and introduces a complete object model."

...then there's this, more reasonable, quote:

"Comparing objects

In PHP 5, object comparison is more complicated than in PHP 4 and more in accordance to what one will expect from an Object Oriented Language (not that PHP 5 is such a language)."

There are basic means for reusability, inheritance and encapsulation in both php4 and php5. If you just happen to adore to use every possible function / OOP method in your script then you have a different sort of problem and it's not of technical nature.

Regarding login script, there exist scripts that are 10-15 lines of code and are used for logging in / logging out. It all depends on the all features you want to employ and you haven't given enough info about that. If you know PHP, go with it. If you know another serverside language, go with that one. Simple as that.

Advantage/Disadvantages making a login script in PHP? All are the same. With php you can use session_register() and $_SESSION variables to authenticate.

http://us3.php.net/session_register

Please note that session_register is *NOT* encouraged since PHP 4.1.0 you have to use $_SESSION. Since register_global is off by default, and if register_global is off, session_register will not work at all. Note as well that register_global will totally not work as PHP 6.0.0 as register_global will be retired.

PHP 6 seems to be adopting better OOP implementation.

OO changes:

Static Binding
A new keyword will be created to allow for late static binding - static::static2(), this will perform runtime evaluation of statics.

Namespaces
It looks like this one is still undecided - if they do implement namespaces it will be using their style only. My advice? Don't hold your breath!

Type-hinted Return Values
Although they decided against allowing type-hinted properties (becaue it's "not the PHP way") they will add support for type-hinted return values, but have yet to decide on a syntax for this. Even so, it will be a nice addition.

Calling dynamic functions as static will E_FATAL
At the moment you can call both static and dynamic methods, whether they are static or not. Calling a dynamic function with the static call syntax will raise an E_FATAL.

The non-compatible changes are probably going to make php 6 a niche market for a couple of years. I am excited about the removal of register_globals. That's been encouraging bad code for far too long.

Please note that session_register is *NOT* encouraged since PHP 4.1.0 you have to use $_SESSION. Since register_global is off by default, and if register_global is off, session_register will not work at all. Note as well that register_global will totally not work as PHP 6.0.0 as register_global will be retired.
Good joke. I'm using PHP 5.2 and all hundreds of my sites use session_register with register_globals off.

Up to you to use best practices or poor code.

From PHP.NET:

Caution If you want your script to work regardless of register_globals (http://ca.php.net/manual/en/ini.core.php#ini.register-globals), you need to instead use the $_SESSION (http://ca.php.net/manual/en/reserved.variables.php#reserved.variables.session) array as $_SESSION entries are automatically registered. If your script uses session_register(), it will not work in environments where the PHP directive register_globals (http://ca.php.net/manual/en/ini.core.php#ini.register-globals) is disabled.

AND



Caution
If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), session_is_registered() (http://ca.php.net/manual/en/function.session-is-registered.php), and session_unregister() (http://ca.php.net/manual/en/function.session-unregister.php).



http://ca.php.net/manual/en/function.session-register.php



I dont think it is documented just for the fun of it.

Thanks guys. :) So what I got from all these replies is this: If I plan on upgrading to 6.0 anytime soon, OOP wouldn't be too bad but otherwise I should just go with imperative programming. Right?

If you find this:



if(user_login(&$username, &$password))
{
}

if(user_is_logged_in())
{
}



more readable and intuitive than:



if($user->log_in(&$username, &$password))
{
}

if($user->logged_in())
{
}



then go with procedural way.

Don't listen to all advices, especially the ones that advise you against OO just because php compared to other languages apparently loses. That's not true and OO wasn't invented so you use absolutely every possible feature that it offers.

For logging in / logging out, you can create a (OO) script within 50 lines of code, it's easier to maintain and extend it when necessary.

Yep but something you forgot maxymizer is by doing the procedural way user_is_logged_in() you have to use global vars, which is far from being the best to manage your code. You then loose the structure & good practices.

By the way if I am not wrong, when you cast the function user_login(&$username, &$password) you have to typecast the reference in the declaration not when you call the function. (but I may be wrong !).

Yep but something you forgot maxymizer is by doing the procedural way user_is_logged_in() you have to use global vars, which is far from being the best to manage your code. You then loose the structure & good practices.

By the way if I am not wrong, when you cast the function user_login(&$username, &$password) you have to typecast the reference in the declaration not when you call the function. (but I may be wrong !).

I didn't want to go in-depth in procedural vs oo, the example was to show the most basic difference and yes, it's a good observation - you have to use global vars in procedural way.

Regarding references when calling the function, it's just a practice that I'm used to. I use references when calling and declaring the function.

As I said, PHP (even version 4) has the basic means for OO - reusability, encapsulation and inheritance and that's more than enough for a simple login script.

For a login script, you will not see any advantages if you go with procedural or object based programming; unless you have an established backend that is using objects.

Just going OO without really understanding its benefits is not going to gain you any speed or performance.

Hm....thanks guys. To be honest I want to create one login script that I can use for more than one large project so I don't have to create a login script for each one.

If you find this:



if(user_login(&$username, &$password))
{
}

if(user_is_logged_in())
{
}



more readable and intuitive than:



if($user->log_in(&$username, &$password))
{
}

if($user->logged_in())
{
}



then go with procedural way.

Don't listen to all advices, especially the ones that advise you against OO just because php compared to other languages apparently loses. That's not true and OO wasn't invented so you use absolutely every possible feature that it offers.

For logging in / logging out, you can create a (OO) script within 50 lines of code, it's easier to maintain and extend it when necessary.

How about this in OOP:


include 'authentication.class.php';

$auth = new authentication('user_id', 'pass'); // Class constructor

// Then thruout the rest of the script:
// $auth->id = user_id if success, false otherwise...

if ($auth->id) {
// Whatever
}

How about this in OOP:

*sigh*

I didn't try to discuss the method that should be used, but for multiple user logins with your script you need to create multiple objects.

*sigh*

I didn't try to discuss the method that should be used, but for multiple user logins with your script you need to create multiple objects.

Huh? Why would he need to create multiple objects if he has multiple users logging in? The object would always be created at the user's runtime and would pull info from the user's session, and would take on the properties of that user -- just like every other user authentication / login object... objects don't persist between pageloads unless you serialize them and store them somewhere.

Huh? Why would he need to create multiple objects if he has multiple users logging in? The object would always be created at the user's runtime and would pull info from the user's session, and would take on the properties of that user -- just like every other user authentication / login object... objects don't persist between pageloads unless you serialize them and store them somewhere.

If you use one class for logging in various types of user and if you require multiple logins (I have a project where I require that), wouldn't it be easier if you invoked a member twice instead of creating a same object just to pass 2 different combinations of usernames and passwords?

If you use one class for logging in various types of user and if you require multiple logins (I have a project where I require that), wouldn't it be easier if you invoked a member twice instead of creating a same object just to pass 2 different combinations of usernames and passwords?

Make a static class then.

authentication::login('user', 'password');

In the class:

public static $users = array();

Which would be ammended like so:

public function login($user, $pass) {
if ( SIMPLE CHECK HERE ) {
self::$users[$user] = true;
}
}

Then in the rest of the scripts:

if (authentication::$users['feedsfarm']) {
// laddi daddi da
}

Make a static class then.

Why? I already posted what I consider more readable and easier. It's a member function that takes 2 arguments and logs you in. I never use any "static" classes, it beats the purpose of OO and is the same thing as procedural code. It's only that your code looks more "leet" because of the usage of scope resolution operator. I think I'll skip that and stick to what's proven to be working just fine for about every single person I work with on daily basis.

;)

Why? I already posted what I consider more readable and easier. It's a member function that takes 2 arguments and logs you in. I never use any "static" classes, it beats the purpose of OO and is the same thing as procedural code. It's only that your code looks more "leet" because of the usage of scope resolution operator. I think I'll skip that and stick to what's proven to be working just fine for about every single person I work with on daily basis.

;)

Benefits are modularity and the ability to inherit the authentication class via other classes.

Why? I already posted what I consider more readable and easier. It's a member function that takes 2 arguments and logs you in. I never use any "static" classes, it beats the purpose of OO and is the same thing as procedural code. It's only that your code looks more "leet" because of the usage of scope resolution operator. I think I'll skip that and stick to what's proven to be working just fine for about every single person I work with on daily basis.

;)

I was just going to say. You create a static class, and then you inherit that static class so that you don't have to write procedural code to process the other logins.

Benefits are modularity and the ability to inherit the authentication class via other classes.

Which is also achievable without creating static class. The topic went the other way, I was referring to your initial example where you passed user login info to the constructor and completely ignored the use of other members and then you mentioned static class.

It can all be done without the use of static class and without passing parameters to the constructor, but to a member that's responsible for logging someone in. It also comes down to preferences - if you find using static class easier - that's up to you. For me it has no advantages.

Read up a bit more on PHP OOP and I've decided to use it. Thanks guys. :D