Thank you for submitting this pull request!

the PDO->execute statement binds the parameters in the same way that bindParam does, it simply uses PDO::PARAM_STRING as a default (see the docs)

So that being the case, how are these changes more secure?

The real security issues were on statements that had something like client_id = "%s" with sprintf. That just gave me the creeps. If someone had sent " OR 1=1 -- or worst in client_id, we would be in serious trouble.

In queries where user_id is used, and because of that int-or-string control, it's just a little more hardened to use PARAM_INT.

The rest was only for consistency sake.

As stated in my inline comment, there is no security benefit of string concatenation over sprintf. Also, we don't need to worry about sql injection on table names, as that should NEVER be left up to user input. As for username/password sql injection, these are open to sql injection attacks, but as we are binding those in the execute statements, sql injection is not possible.

Since this class is NOT for production use (I will add a comment saying as much... and I apologize for the confusion) the user_id enhancement is not desirable. It is meant to be a proof-of-concept / tracer bullet / whathaveyou.

Thanks for your support!

As I said, string concatenation was only a panic option, and then my coding style took over; the real security issue was inline insertion of parameters, as in line 45, for example. There's nothing wrong with the sprintf (or string concatenation, for all that matters), as long as there's no direct parameter insertion.

This is not production ready; but it could be. Then, all it could take was the override of the password check, and that was it.

Is it possible to change the visibility of properties in "protected" ? To easy extend functionality ?

If there is a convincing reason to do so, then yes. However, any time a property or method goes from private to public, or public to protected, you are adding entrypoints into your model. This makes it very hard to refactor later, as anything might break backwards compatibility depending on how its used. For this reason, it's best for things to default to private and move to public only if there's a reason.

Which properties do you think should be protected and why? Also, this should be a new thread...

Thanks for your answer.
I would like to override method "getUser($username)" using $db property in my extended class.
But I can find a workaround ;)

sounds reasonable! Will you send me a pull request?

I have sorted out but I will send you a request. Thanks!