New upcoming site
Reusing accounts with OpenID
Internal OpenID deployment
Scheduled migration down time
What will change?
Better account security measures
New upcoming site
As I mentioned before, in the next days a new site of user contributed content for Web developers will be launched.
The site may require that you to have an account to access some of its resources, but it would be a drag if you had to create yet another account in the new site to access it.
Reusing accounts with OpenID
Fortunately, the new site will use a new solution that has been implemented in the last 4 months which lets you reuse your PHPClasses site account in the new site.
The solution was implemented by creating a new central site, named Icontem Accounts. It will just take care of authenticating users and managing some of the account options.
This central site acts as a provider of account validation. It supports the OpenID protocol for validating the user account and password and exchanging account information with the PHPClasses site, as well with the new site that will be launched.
But do not worry, all this will be transparent for you. The main thing that will be different for you is that your user and password will be requested in a form that appears inside an iframe which will be presented in the PHPClasses site login page.
The login form iframe shows a small logo of the Icontem Accounts site. Other than that, you may not even notice that it is an iframe opening a page of the Icontem Accounts site. It will be very similar to when you access to Google services that require that you have a Google account.
Internal OpenID deployment
OpenID is an open protocol that many sites can use. Usually it allows you create an account in one site and reuse it in another site.
However, the deployment of this OpenID implementation is intentionally restricted to the PHPClasses site, the new upcoming site and eventually any other future sites managed by Icontem.
This means that you will not be able to use OpenID accounts created in sites of any other networks (such Google, Yahoo, MSN, Wordpress, etc..). You will also not be able to use OpenID accounts created in the Icontem Accounts site in other networks.
It will all be restricted to the Icontem network. Therefore you will never be asked to enter your account URL as you see in some sites that support OpenID. You will just be prompted for your user name and password. This is much simpler and safer than in other networks that require you to memorize or copy and paste OpenID account URLs between sites.
Scheduled migration down timeThe Icontem Accounts site will have a separate database of with user records. Therefore it will be necessary to migrate to that database more than 925,000 accounts that the PHPClasses site currently has.
During the migration it will be necessary to disable the access to the PHPClasses site user accounts in order to prevent eventual inconsistencies caused by users that would change their accounts before the migration is completed.
Therefore the site will held in maintenance more during the migration process. This process is expected to take a few hours. If all goes well, it should not take more than 7 hours to complete. That is why it was scheduled to this Saturday (August 14, 2010), as that is the day of the week with the lowest traffic.
What will change?Once the migration is completed, the PHPClasses site will be back to its normal operation. Next time you will have to login the site will show you a slightly different login form that appears inside an iframe in the middle of the login page.
The login form is in reality a page of the Icontem Accounts site. You will see a logo of the Icontem Accounts site near the form. Once you enter the correct user and password, the login form page is redirected back to the PHPClasses site, so it starts a new login session.
Other operations like password recovery or editing of the account options also happens in the Icontem Accounts site. But don't worry, this should be all transparent for you and you will not even notice that you are actually accessing a different site using an iframe.
Any users that register to the PHPClasses, ask to change their e-mail address or asked for password recovery help but do not complete that process before the migration is started, will have to restart the process in the Icontem Accounts site.
Better account security measuresSince the Icontem Accounts was practically developed from scratch, several measures were implemented to provide better security to your account information.
One of the measures is that the Icontem Accounts is only accessible via SSL. Several aspects of configuring the SSL server were taken care in order to avoid security pitfalls of incorrectly configured of the SSL environment. What exactly was done is an advanced topic outside the scope of this article, but I may get back to it in a future article.
Other than that, the account password and e-mail address can only be changed in the Icontem Accounts site. Other account options such as the personal name, date of birth and country name can either be changed in PHPClasses or in Icontem Accounts.
The OpenID protocol will take care of the synchronization of the information. Several measures were put in place to avoid eventual exploits that could be caused by attackers sending forged OpenID requests.
That is one of the reasons why the OpenID consumer and provider package were implemented from scratch for this project. These packages are not specific for these sites. They may be made available as Open Source later when I have more time to document, for the benefit of the whole PHP community.
Another aspect is that the Icontem Accounts site implements Cross-Site Request Forgery (CSRF) attack prevention measures in most security sensitive forms. It consists basically of using random tokens passed in hidden form fields. These tokens expire after a while. If you take too long to submit such forms, the site may ignore it and ask to submit the form again for security reasons.
Don't worry, that is normal. This is a measure to prevent that attackers reuse previous tokens to change your account details without your knowledge and permission by performing CSRF attacks.
You may also notice that when changing the account password or e-mail address you will be prompted to enter the account password. That may be a small annoyance that is necessary to provide better security.
It will prevent that somebody accesses your computer while you leave it with your browser opened and logged in the site, and then changes your password and e-mail without your consent. It also prevents eventual Cross-Site Request Forgery attacks that could be used to make you change your account e-mail address without knowing.
Once an attacker makes you change your e-mail address to an address of his own, he could request to change your account password and then take over your account.
Unfortunately, many sites were implemented without this level of security concern. If that is the case of any of your sites, I strongly recommend you to revise your security attack prevention procedures.
That is all for now. If you have comments or questions about the migration, the upcoming changes or the security measures that were put in place, feel free to post a comment to this article with your questions.