AzoftSpotlightBinding account Login – Pros and Cons

Binding account Login – Pros and Cons

By Alexandra Weinstein on April 13, 2011

Some time ago I was taking part in a discussion to the topic «Do we need to make authorization via external services in our new project?». The beautiful pop-up ads, widgets and other decorations demanding "Enter me!" spoke for it, besides the modern web-two-zero (or even web-three-zero) tendencies of big portals development also suggest it. But I started with that there was a discussion, which means there were different opinions to the question. Let's suppose a web site has a smart panel or just separate authorization widgets, e.g. via twitter, Facebook etc. Is it easy to enter the site? Of course. But for all this if a person will enter it from all his accounts (at the same time or not), these will be different people for the system, thus these are clones of one and the same person, who probably isn't a registered user at all. You'll say what's the differ to register an account on a web page or to enter via external recourses? Everything here depends on the scope of our project. If we have quite a targeting site, e.g. where you can read some news or write comments, we can content ourselves with external services. And what if each user is a big world on the web page with his articles, advertisements, rates, wine factories and open space shuttles? After studying the available recourses and API of the most popular services we came to the conclusion that all of them work similarly. A person sends via widget a request to the external recourse, the request contains the user identificator for this recourse, some data about the account and a secrete key, formed with an accessable for developers algorithm. And developer can use these data on the site in his own way. After some googleing and analyzing the results we invented an other method, which actually solves the task of person identification – binding. First we'll need three tables in a database. Let's name the first table "Users", there will be users registered on our site. The table can have any structure. Obligatory are the fields:

  • User ID
  • Login
  • Password

The second table will contain a list of recourses allowed on our site, e.g. Twitter, Facebook etc. It should look like that:

  • Recourse ID
  • Recourse name (e.g. Facebook)
  • Machine name of recourse (e.g. facebook)
  • Place for user identificator in the link (e.g.{ID})
  • Application ID (in our case the one of our site) on this recourse

And the third table, which is probably the most important one "Links" will include the user account compliances with his account on an external recourse. The table should include:

  • Link ID
  • Recourse ID
  • User ID on our site
  • User ID on the external recourse

Also we should have appropriate  presentations (pop-up windows or similar)  for all recourses on our site. They will call the needed widgets and functions (classes, helpers, modules etc) that will calculate and check an appropriate API key. Let's assume we have a site with a traditional registration form and a panel with some widgets of external recourses. When a person enters/registers on our site traditionally, after the final authorization procedure he gets directly on our site or to his panel, where he sees settings section. When entering this section he will see there a panel, e.g. "Profiles on external recourses", where there will be field created in our External recourses Table. For instance the user has chosen the field "Facebook" and entered there his password. How the process will start – when loosing input focus, or when pressing a button, or thanks to UFO – it doesn't matter for us, we want to know the outcome. We start an appropriate authorization procedure of an appropriate widget (pop-up window, ajax-request to the needed script or something else). If the user is already authorized on the external recourse we'll get the required data, otherwise the user will need to authorize himself, and we still will get the data. Here the magic starts. The key from a recourse is a hash or a data set, where user identificator on the remote recourse is kept. First we using our key generation procedure create a key using the user identiicator. Then we compare the key that came from the recourse with our key. If two keys and identificators match we have to deal with a registered user. In this case we create a string in the "links" table, and the identificator becomes unique, nobody now can enter the same one. In case when the keys didn't match you have to scold the person for trying to steel somebody's identificator, or you can ask him politely whether he entered everything correct. All this works for any external recourse that a user might want to use. This was an easy version. Little bit more difficult it will be when authorizing via external recourse without any registration on the site. In this case we skip registration. After a person entered the site, let's say via Facebook, a session will open for him and he will see a big note: This user %recourse name% isn't bound to any accounts registered on the site. You can bind it to your account right now, or you can create a new one. Actually that's it, to motivate the user to bind himself to any account we will limit his rights, e.g. he will be able only to view the content. Of course if the person will click on any link in the note he will be able  to enter his login and password and will be automatically registered. You think it's severe to limit users without a real account on a site. I can agree with it. But after he follows an easy registration procedure one time, he later will be able to enter different recources via one mouse click. Anyway even the registration request can be implemented in the best traditions of web-two-zero, so it won't be annoying, but at the same time it will make a slight hint.

Enhanced by Zemanta