Sample database design for table name contact.
This table contains id (primary key),tutorial and link.
CREATE TABLE IF NOT EXISTS `google_login` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(500) NOT NULL, `email` varchar(500) NOT NULL, `inserted_on` datetime NOT NULL, PRIMARY KEY (`id`) )
Contains database connectivity code
$mysql_db_hostname = "Host name"; $mysql_db_user = "UserName"; $mysql_db_password = "Password"; $mysql_db_database = "Database Name"; $con = mysql_connect($mysql_db_hostname, $mysql_db_user, $mysql_db_password or die("Could not connect database"); //Create a new connection mysql_select_db($mysql_db_database, $con) or die("Could not select database"); // select database
OAuth Login is very quick and powerful, sure this helps you to increase your web project registrations. It’s definitely a must have login system for every PHP based web projects. Hardly it will take 10 mins for installation.
OpenID is an old standard. In fact, it hasn’t even been updated since 2007. In its path, however, it has picked up some great sites. For that matter, even Facebook allows you to sign in and use its site via OpenID and users can link their Gmail accounts to the site in the same manner.
The purpose behind OpenID can best be described as an introduction to a stranger. OpenID serves as the third party that can verify who you are. So, when you go to sign in to a new site, the site asks the OpenID server “is this John” and the OpenID server replies that yes, it is John.
The problem with OpenID, according to Dave Recordon, is that v2 of the standard was incredibly difficult to implement:
I’ve heard story after story from developers implementing OpenID 2.0 who don’t understand why it is so complex and inevitably forgot to do something.
So, combine that complexity with the fact that OpenID hasn’t been updated in 3 years and you have a bit of a recipe for disaster. There’s also the problem that it requires more than one handshake (introduction) in order to get data stored on a server. In fact, OpenID cannot, at this point, acquire that information on its own. It has to send a second request for OAuth to handle the information transfer.
There is hope on the horizon, however. Rumors are swirling that OpenID is working on a new standard called OpenID Connect that will be built on top of OAuth. This would allow a single handshake for both identification and data transfer. We’ll do another post about that, later, as more developments happen.
In a few words, OAuth is “a simple way to publish and interact with protected data. It’s also a safer and more secure way for people to give you access.” Twitter has implemented it, with the@anywhere platform, as have a number of other sites around the Internet. Version 2 of OAuth, released in May of 2010, is a complete revision of the platform that is purposely not backward-compatible with previous iterations.
OAuth differs from OpenID in that it cannot request identification (at least in its present form). What it can do is allow a 3rd party to have access to your data without the need for you to show your password to that 3rd party site. There is a revision to OAuth that has been proposed, allowing OAuth to acquire identity as well, but it is far from finalized.
That 1.0 version of OAuth had issues of its own. In fact, it spawned the discussion about WRAP, yet another manner of doing the same thing. While the WRAP discussions have gone to the wayside, you can rest assured that the involved parties are watching the current circumstances quite closely.
OpenID allows a site to make sure that its user owns some personal URL (of a site, blog, profile). This fact is sufficient to use this unique URL to recognize the user next time he logs into the site. That’s it. Everything else — registering accounts, obtaining emails and other data, permitting any activity on the site — is up to the site itself. In other words, OpenID is a pure authentication mechanism: you know who’s come upon your site and you can do with this knowledge whatever you like.
OAuth allows a program (on the web or local) to obtain from a user certain rights to use a particular API. The rights are denoted with a token whose nature is not defined: it can be the same for different users or the same user can be granted different tokens at different times. The only thing guaranteed is that upon presenting the token to the service the program will be able to perform certain actions on it. In other words, OAuth is a pureauthorization mechanism: you have certain rights but you can’t infer their owner’s identity.
Here’s an analogy. OpenID is your driver’s license: it says who you are but it doesn’t imply you’re going to drive a car whenever you’re asked of your ID. OAuth is you car’s key: a valet can drive your car with them but he doesn’t need to know your name to do it.