In general, the solution to small files is to read the file directly on the server and then output, thus avoiding the exposure of the file address, which is a solution. What I want to say now is to use the TransmitFile method to output files directly, but how much does this method support for large files, and how much performance overhead, I have not tested, interested friends can test and comment.
Well, to get to the point, the general download station, we thought is the flow of the problem, so automatically thought should be the file and program code separate deployment. So I gave the file a separate two-level domain name, we call File.xxx.com bar. The main site domain name is www.xxx.com, or other two-level domain names are OK.
The first step is to implement the authentication between the 2 sites shared, such as landing the main station after automatic substation login, that. NET forms authentication is easy to achieve this function, the bottom line of thinking is actually the principle of sharing cookies. The second part is to the file station do permission filtering. Next we add Web.config to the main station and to the file station. To add them to the same configuration, the Web.config main configuration code is as follows:
Copy Code code as follows:
<?xml version= "1.0" encoding= "UTF-8"?>
<configuration>
<connectionstrings>
</connectionStrings>
<appSettings>
</appSettings>
& L t;system.web>
<authentication mode= "Forms" >
<forms loginurl= "~/home/logon" defaulturl= "/" timeout= "slidingexpiration=" "true" Name= "File" path= "/" enablecrossappredirects= "true" ></forms>
</authentication> <machinekey validationkey= " Aaa977d304fb289c182e00c710a099c9f92986dc25ad69f8 "decryptionkey=" aaa2b3f76a9359431e717ca8275ee72eeedc70ed55152010 "validation=" SHA1/>
</system.web>
<!-- This node only needs to be added to the file station--> <system.webServer>
<add name= "*.* path=" *.* "verb=" * "type=" Web. Handler.download "/>
</system.webServer>
</configuration>
The above profile addresses several key configuration points for Cross-domain access: Authentication name is the same, path= "/" indicates that the cookie store path is the root domain, enablecrossappredirects= "true" Indicates whether authentication can be redirected to another application. Two: The HttpCookie node is configured as a top-level domain name. Three: The machinekey of two sites must be the same. That is for permission control, by implementation. NET inside the access filter, that is, the IHttpHandler interface, used to intercept access. The implementation method is also very simple, as long as the implementation of the ProcessRequest method can be, the following is my code:
Copy Code code as follows:
Namespace Web.handler
{
<summary>
File Download Login Verification
</summary>
public class Download:ihttphandler
{
public bool IsReusable
{
Get
{
return true;
}
}
public void ProcessRequest (HttpContext context)
{
if (context. User.Identity.IsAuthenticated)
{
String fileName = context. Server.MapPath (context. Request.filepath);
Context. Response.ContentType = Path.getextension (fileName);
Context. Response.TransmitFile (context. Request.filepath);
}
Else
{
Context. Response.Write ("You are not logged in!") ");
}
}
}
}
After writing the above code, that is to increase the filtering configuration, note the configuration file note above, the most important configuration section: <add name= "*.*" path= "*.*" verb= "*" type= "Web.Handler.Download"/> Name is the names of the filters, just fill in, path means that you want to filter the file suffix, I am all files need to filter, so directly with *.*, if only to filter jpg and GIF, can be changed to: *.jpg,*.gif, type is the filter DLL address, That is, we implement IHttpHandler class full name, OK, file access control has been completed. Note: Since I am using IIS7, the handler here is added to the System.websever node, IIS6 and the following versions are added directly to the system.web node.
