In the B/s system development, often need to use "authentication". Because the Web application is very special, unlike traditional C/s programs, by default (no authentication method and authority control means), when your program is publicly available on the Internet/local area network, anyone can access the resources of your Web application, which makes it difficult to secure your application. Popular point: For most internal systems, business support platform, and so on, users must log in, otherwise can not access and operation of any page. And for the Internet (site), there are some differences, because most of the Web site most of the pages and information are open to the public, only related to the registration of user personal information operations, or the site's background management, such as the need to prompt login. (If you do not do rigorous validation, the consequences will be very serious, people once guessed your web directory under the name of the page, you can access.) Of course, the average developer does not make this low IQ mistake.
How to implement "Authentication"
Remember n years ago when I first contacted the servlet + JSP development, there is a kind of thing called "filter" (filter), it is very magical. With this magical thing, I no longer need to go to each page to judge what "session" or "cookie", you can put the unregistered user to pop-up (level implementation is limited). Of course, in the traditional WebForm development, you can also write a "basepage of chicken", in the class to make judgments, so that each page corresponding to the class to achieve this "chicken", I think a lot of companies have done this before.
In ASP.net, Microsoft offers a complete set of mechanisms to implement "Member role management". Includes: Login controls, membership, personalization database, and more. But most developers never use these (for example, I, with Microsoft's ASP.net 34, have never seen anything like "Login Controls"). In asp.net authentication, there are mainly three or four kinds. Because some authentication methods are dependent on IIS and the Windows operating system, there are some differences in different versions of the operating system and IIS. Since I'm using the Windows 7 operating system for the time being, take IIS 7.5 as an example.
The first time you open IIS, and then double-click Authentication on the right, displays all the authentication methods that are currently supported by IIS (since I installed IIS, I checked all the options in "security"). You can see as shown in figure:
Roughly divided into the following categories:
1. The client certificate of the Active Directory (this is likely to be a charge), not commonly used, do not elaborate.
2.ASP. NET emulation (MSDN: If you want to run a asp.net application in a non-default security context of an asp.net application, use asp.net impersonation.) I don't understand what the robot says.
3.Form Authentication: This one is used a lot, and later will elaborate.
4.windows Authentication: Authentication for users who are based on Windows operating systems or for domain users.
5. Basic authentication: In fact, it is also based on the Windows operating system account verification.
6. Anonymous authentication: Anyone can access it, and it is accessed internally by specifying a user account for a particular Windows system.
7. Digest authentication: Use a Windows domain controller to authenticate users who request access to the content of the WEB server.
Take a look at the classic IIS 6 screenshot:
Note:. NET Passport can be understood as Microsoft's "single sign-on" one of the implementation, not in detail here. Interested friends can refer to http://baike.baidu.com/view/1182418.htm and related materials. In the "Open API" "SOA" "Cloud computing" is a great way today, as a web programmer, if you have not heard of "single sign-on", please purchase the move to Fuzhou direction of the ticket.
Test Basic Authentication on IIS 7 first:
First, disable all other authentication methods, and then only enable Basic authentication. There is a picture of the truth:
Then open IE, FireFox, Chrome and other browsers, typing localhost, waiting to open the default Web site on IIS. You'll notice that the browser side pops up the balloon message, and there are differences in the styles and manifestations of pop-up boxes on different browsers. (For a long time without IE, found 360 this old rascal to change the home page of elder brother, also known as "safe Internet", this is obviously tamper behavior. I don't understand. ）
If you are in the pop-up box, enter the correct Windows account and password, you can normally browse the page you requested. If you do not lose or lose the wrong, waiting for you will be 401 errors (401, you know).
"No SSL is enabled for the Web site, it will pass through the cable in plaintext ...", the robot said it sounds awkward, here, I explain.
When you don't have to pay to buy SSL certificates (Secure Sockets Layer, you can simply understand that: normal HTTP requests are plaintext transmission, using SSL can help you to automatically encrypt HTTP messages, even if someone intercepted on the internet can not decrypt. When we occasionally visit some websites, we see "https://www.xxx.com", most likely in the form of SSL certificates. As for "through the cable in clear text of the way ...", in fact, this sentence is very wrong, first of all, the cable is only a transmission medium, which transmits only electrical pulses, light signals, and so on, rather than network protocol messages (learned computer networks are known). As for the "Use of the form of clear text," is not true, in fact, "Basic Authentication", is the user name and password used BASE64 encoding, interested readers, can use HttpWatch or fiddler such tools to monitor HTTP requests, I do not do a demo here. Just because the base 64 encoding is easily deserialized, it is no different from plaintext. In this way, you will find that there are many unsafe factors in the "Basic Authentication" approach.
Test Windows Authentication on IIS 7:
Similar to the previous Basic authentication, I no longer have screenshots to demonstrate. If the user enters the correct Windows user name and password, the Web site can be accessed normally. If the error is entered, 401.1 is returned (the preceding Basic authentication is 401.2). It is worth mentioning that, remember a previous asp.net MVP once told me that when using Windows authentication, only users in the use of IE browser can be normal access. In this case, instead of using the form of HTTP message transmission, the browser side interacts directly with the operating system to authenticate the username and password. It was confirmed that the second half of the sentence was true, and that the HTTP entity content was not really monitored. But not only in IE browser, I am in Firefox can also be normal access and use.
Anonymous authentication, in fact, can be understood as "do not verify." Is that anonymous users have access to resources without any restrictions. Typically, our web site will enable anonymous authentication and Integrated Windows authentication. It is not hard to find that Anonymous authentication is also validated by a specific user within the Windows user group, as shown in the figure:
The last one, form authentication:
The authentication methods mentioned above are not directly related to ASP.net, but are both IIS and OS level authentication methods. Form authentication, however, requires asp.net support. Because the common Web site authentication and member management are very complex, rather than through a simple authentication method can be achieved. For most Internet sites, users can access part of the page, but some pages must be logged in order to access and operation, and different user roles login, operation permissions are not the same. This will involve many aspects of knowledge, but also the implementation of a variety of ways.
Due to its limited space and time, we are here today. Later I went into detail about form authentication details and member management, rights management aspects of the article, please look forward to.
This article originates from http://www.cnblogs.com/dinglang/.