Step 1 log on to the system with an account (9. Summary and source code download)

Because there are still many tasks not completed during this shutdown period and the schedule is not enough, the series can only be ended earlier than originally planned.ArticleBut all the content to be introduced has been introduced, just to sort out the source code in advance.

Because this is a summary post, first list the content of the previous nine articles:

Step 1 log on to the system with an account (0. Overall approach)

Step 1 log on to the system with an account (1.ProgramStructure)

Step 1 log on to the system with an account (2. BasicsCode)

Step 1 log on to the system with an account (3. log on to the website using Google's auth sub)

Step 1 log on to the system with an account (4. log on to the website with the Windows Live ID)

Step 1 log on to the system with an account (5. log on to the website with Yahoo bbauth)

Step 1 log on to the system with an account (6. log on to the website with openid)

Step 1 log on to the system with an account (7. Use the opensocial interface to log on to the internal network user)

Step 1 log on to the system with an account (8. Implementation of step1.accountclient)

At the bottom of this article, the entire source code will be included. Before that, I would like to briefly explain some of my experiences and notes:

1. regarding the security of the system, the system consists of four roles: end user, web application (accountclient), accountserver, and account server, each role needs to consider its own role security issues as follows:

A. users do not want to enter their accounts and passwords on untrusted websites, and they only want to provide their authorized materials to Web application websites, this function meets the requirements in the system. In fact, this is also the core principle of the system design;

B. the most important security considerations for web applications are that they are not spoofed by the disguised accountserver. You must know that accountclient obtains user information and saves it as a cookie by receiving URL parameters, assume that a disguised URL parameter can actually fool web applications. In the source code provided by me and the current online system, the interaction between accountserver and accountclient is not encrypted. This is because it is only a research project. When I do need to log on to the system to develop applications with high security levels, security restrictions will be added. You can assign a secret key to each web application by referring to the account server method of accountserver, for example, MD5 verification for the URL parameters transmitted by both parties;

C. accountserver has two security aspects. On the one hand, it avoids the spoofing of the disguised accountclient. In fact, this spoofing has little impact. The MD5 verification method mentioned in B can prevent this spoofing, another aspect is to avoid spoofing by disguised account servers, which is related to various account service types, such as Google's authsub. In fact, there is no secret key for the interaction between the accountserver and the authsub server, it is likely to be disguised, because this disguise does not affect Google's authsub server, but only affects the program that uses the authsub server, so Google is not very concerned. Similarly, the opensocial mode used by my internal network does not add a key to the revolving request. In this opensocial app mode, it is difficult to add a very safe key;

D. As for the security of each account server, the account Server Provider needs to consider it. Therefore, it is not discussed in this article;

2. you may notice that each account type, especially Google's authsub, Yahoo's bbauth, and live ID, except for completing the user login process, I am also very dedicated to getting the user's e-mail address. I use the address book reading method for Google accounts and live accounts, and I use the Ymail sender address reading method for Yahoo accounts, these methods require additional information access permissions to users. Why do I need to obtain the user's e-mail address? In fact, these account services provide a unique ID. Why not use these IDs as the user's account directly? Because I cannot trust the ID provided by the account server, taking Yahoo's bbauth as an example, I found that after I applied for a new bbauth application, I found that the ID of each login user has also changed. Although the ID of the login user is unique for each application, however, no one can guarantee that there will be no need to change the domain name, re-add permissions, and so on when you need to re-apply for the application, if the re-apply for permissions causes loss of information for each user, the problem will be big. Therefore, the account server claims that the unique ID is untrusted, or the user's Logon account is relatively reliable.

3. users may have different account types. When users log on to the system with different account types, the system will definitely consider them as different accounts. Moreover, the Web application determines whether a user is the same. In addition to the user ID, the Account type must be added, because the same account type of different websites cannot be considered the same user;

The following are the two source codes of the system: accountclient and accountserver:

Download step1.accountserver source code

Download step1.accountclient source code

The end of this series only represents the completion of the first phase of the study. I will continue to optimize the system later and will continue to discuss the issue, but it will not be so intensive for the time being.