Expand |
Embed | Plain Text
Comments
Subscribe to comments
You need to login to post a comment.
Unfortunately if you call the login or check functions without first escaping the username and password you could fall victim to SQL injection. You should make sure you escape those strings before placing them in a SQL query.
Also, whoever uses this class will need to implement the database class that you are using. Is that included somewhere on Snipplr?
check out :
http://phpmylogon.sourceforge.net/
It is way better than this code.
I don't know if it is a good idea to store(even the md5hash) the password in the cookie! It would be better if you'd store a newly generated fakesessionid in the database and the cookie.
yeah the password should only be used during login and not carried around, there's just no need to.
Password hashing and input sanctifying aside, great job mate! Now if only more people writing PHP would follow suit and started building more modular web-applications, well then maybe other developers will start taking us seriously! :D
I agree with lanLewis (May 19, 2007), the_coder (February 18 2008), and MMDeveloper (February 27, 2009.
Every once in a while i come across a "login" script or class for PHP that hints the prospect of being a complete solution. Each time i look through the code i realize the same practices are still being applied, and i wonder just how many sites i registered with and sign in to that may have my personal information stored in some SQL backend.... that use weakly constructed scripts or classes like this one. gringe
That was one of the driving forces behind my eventual development of Commnetivity. The php framework is about a year in development (full time) it's login system was developed from the ground up keeping in mind that not every website will use the typical username/password or email/password credential scheme, and since SSL certificates and hosting with dedicated IP's are now available dirt cheap. (One SSL cert allowed per 1 IP in most hosting environments), the software also forces SSL where applicable. I would love to release the source code for the software... but i also have to feed myself. So instead, i offer a bit of advice to beginner programmers and even the advanced programmers alike:
PHP is a great language if you can call upon your experience in old-school website CGI development. (Perl, Python... and going way back... compiled BIN scripts.. yes... that's where cgi-bin comes from :) ) If you dont have experience, then i would highly suggest you learn about RFC standards (http://www.ietf.org/ and http://www.rfc-editor.org/rfcxx00.html are good places to start) and also look into using flowcharting as a powerful way to understand what is going on in your scripts. A lot of times coders will write scripts without a plan.. generally a failure to plan can be a failure of security or performance.
Also, look into writing in the OOP (object oriented programming) method. I'm not perfect, i still find myself in the MySQL forums looking for answers or hints to solutions, but i have taken the time to understand the naming conventions of the language.
For advanced programmers, it would be wise to realize that any language has its strong points. Perl, Python and PHP are probably the best languages for system administrators, website developers and for windows hosting environments as well. However, the majority of website "developers" or webmasters out there are scripting in PHP.. and as you might be aware, PHP allows for scripting in ways that is not only an eyesore, but a source of headaches when browsing through these user created scripts. I would highly recommend that the practice of embedding XHTML and PHP into one document be extremely limited unless the website owner enjoys expending time and money on future website development. This also leads me to to my next thought:
The reason Commnetivity was developed in PHP was for that simple reason mentioned herein: That php allows for embedded scripting XHTML in a "natural" fashion. (Commnetivity forces users to write clean, simple but powerful scripts) Unfortunately, embedded scripting has many little drawbacks including some bigger drawbacks. We humans have a lot of memory to work with.. however.. most of us think using a little bit of it at a time. It'd be best that we dont stare at a bunch of nonsense to see the bigger picture....the bigger picture being the actual logic and architecture of our scripts. We ignore that, and we have security and performance issues. A really well designed website starts with a platform that can let the website stay fast, secure, scalable and adapt rapidly to an ever evolving business model (fixed business models work well, for some, but not for majority nowadays). By adopting to PHP for this project i did myself a favor and stopped hating PHP and started hating those who contribute bad code (they KNOW others will run with it... ), and i also am hitting a market of those out there who just want to get their websites up with an easy to use, but powerful framework that lets them focus not on "learning" a new system.. but instead on the simple logistics of their projects. (The only rules are that they write clean code. Commnetivity will clean up the code and run a clean version until a new copy of the garbage code is detected.. then clean it again and run the clean copy... until a new copy of the garbage code is detected... then cleans it again and runs the clean copy.... until ... you get the point. )
Thank you for taking the time to read my rant. :)
Wow this is the first time ever I read about a clear mind objective of coding theories. Even if I'm reading multiple and thousand point of view on the subject for me; a starter programmer without school learning.
Excuse my poor English !
This snippet is rubbish. Queries are vulnerable to SQL Injection since they're not parameterized. Use of curly braces is inconsistent reducing readability. Username and password are being stored on the client-side in a cookie which adds no value, is insecure, and is totally unnecessary with the use of session. The author shows a fundamental misunderstanding of the power of session - A simple session var tracking user status on the server side would suffice and avoid the security issues of storing credentials on the client side.
The cookie should only contain a unique ID that cannot be predictably replicated, and nothing more. Everything else can and should be safely stored on the server. You loose control if you just leave stuff like hashes floating around in people's browsers.
Generating a random salt for every new password is also a good idea.
It never ceases to amaze me on how many people LOVE to rip on other peoples code and not post THEIR BETTER solution. Hey "housecor " if you have all the answers and better code then why don't you post it here? I didn't write this code and I am also just learning. This code has been here since May 19, 2007 and around 8 people who ripped on it, and to my knowledge, without posting their better solution.... SHAME head shake SHAME....
he's using php's built in mysql or mysqli class with the current setup, so there's no need to re-implement his database class, unless you're running a version of php that does not have those builtins.
This code isn't much use without a good example of how its properly implemented.