博客园_不如来编码-luminji's web

Asp.net安全架构之2：Session hijacking（会话劫持）

2012-05-30T00:34:00Z

原理

会话劫持是指通过非常规手段，来得到合法用户在客户端和服务器段进行交互的特征值（一般为sessionid），然后伪造请求，去访问授权用户的数据。

获取特征值的非常规有段主要有如下几种：

首先是猜测的方式，如果我们的sessionid的生成是有规律的，那么使用猜测的方式就可以到达非法获取的目的，如图所示：

其次是session fixation攻击。session fixation攻击是指用户通过XSS、网络嗅探、本地木马来得到特征值，这些交互的特征值一般来说放置在浏览器的Cookie中（当然，我们也知道sessionid也可以通过URL来传递，这样的话，获取就简单多了）。然后诱使用户去完成一次登录（诱使的方法可使发邮件，发链接等）。如果服务器没有更新这个SessionID，则攻击者可以凭借此SessionID登录系统，如图所示：

在特征值被获取到之后，攻击者还可以使用Session保持攻击，这一般是指写一段小代码，定时发送请求，保持Session有效。这样，攻击者，就可以一直利用这个合法用户进行非法活动。

实际案例

在http://yourdomain.com/default.aspx界面，我们偷到了sessionID，然后就可以模拟这样的请求来完成一次攻击。一次攻击是指，拿上如下的请求，我们可以在任意客户端进行登录。

User-Agent: Fiddler

Host: 192.168.40.193

Cookie: LoginName=luminji; ASP.NET_SessionId=xzyplp45wgl3rf45ssxt5h55;

同时，在客户端写一段脚本，还可以完成Session保持攻击。经过这样的处理后，非法用户不用登录系统就可以访问任意页面了。

应对策略

1：为Cookie设置httpOnly，就可以有效防止Cookie被非法读取，从而防止劫持；

2：每次登录更换SessionID。

具体措施

n 查看sessionid生成策略，确保不可被猜测

备注，sessionid在asp.net程序中是被自动生成为GUID形式的，所以在Asp.net程序中该项不需要被修改。

n 查看sessionid保存策略，确保不通过URL进行传递

n 每次登录更换sessionid

改进登录模块，每次登录更换sessionid。更换sessionid并不会影响有些站点的类似“一个星期”都不用登录的功能。如果攻击者不是从合法用户的本机获取的sessionid，那么完成此次升级后，session fixation攻击就被阻断了。

更换SessionID的函数为：

private void ChangeSessionID()
{
SessionIDManager m = new SessionIDManager();
m.RemoveSessionID(Context);
HttpApplication ctx = (HttpApplication)Context.ApplicationInstance;
HttpModuleCollection mods = ctx.Modules;
SessionStateModule sessionStateModule = (SessionStateModule)mods.Get("Session");
System.Reflection.MethodInfo CreateSessionId =
sessionStateModule.GetType().GetMethod(
"CreateSessionId",
BindingFlags.Instance | BindingFlags.NonPublic);
System.Reflection.MethodInfo InitStateStoreItem =
sessionStateModule.GetType().GetMethod(
"InitStateStoreItem",
BindingFlags.Instance | BindingFlags.NonPublic);
CreateSessionId.Invoke(sessionStateModule, null);
SessionStateUtility.RemoveHttpSessionStateFromContext(Context);
InitStateStoreItem.Invoke(sessionStateModule, new object[] { true });

FieldInfo sessioninfo =
this.GetType().BaseType.BaseType.GetField(
"_session",
BindingFlags.NonPublic | BindingFlags.Instance );
sessioninfo.SetValue(this, HttpContext.Current.Session);
}

n 确保登录逻辑不仅仅依赖sessionid

如果登录逻辑不仅仅依赖sessionid，攻击者将需要得到全部的特征值（一般情况下，就是说意味着他要得到全部和登录相关的cookie值），这加大了攻击难度。

n 确保Cookie的httponly

通过文件查找所有的”cookie”，找出所有设置cookie的地方，为用于认证的cookie设置如下的格式：

Set-Cookie: cookieName=cookieValue;httponly

本文链接

Asp.net安全架构之1：xss（跨站脚本）

2012-05-22T00:23:00Z

原理
跨站脚本（Cross site script，简称xss）是一种“HTML注入”，由于攻击的脚本多数时候是跨域的，所以称之为“跨域脚本”。

我们常常听到“注入”（Injection），如SQL注入，那么到底“注入”是什么？注入本质上就是把输入的数据变成可执行的程序语句。SQL注入是如此，XSS也如此，只不过XSS一般注入的是恶意的脚本代码，这些脚本代码可以用来获取合法用户的数据，如Cookie信息。

其原理如下图所示：

XSS从攻击原理上，分为三类：

1：反射型XSS

    将用户输入“反射”回浏览器，即将用户的输入变成HTML传输回客户端。如：
          Response.Write(“<script>alert(/xss/);</script>”)
    就是一个典型的反射型XSS。

2：存储性XSS

存储性XSS本质上也是一种反射型XSS，但是它把攻击脚本放置在服务器端，一旦被注入，可被多人多次利用。如，发表博文，就可以引入存储性的XSS。

3：DOM BASED XSS

如果用户的输入被用于修改原有HTML的DOM内容，就会引入这一类攻击。

最典型的是输入的内容用于作为某个节点的innerHTML，如果不对输入作验证，则会被注入攻击代码。

    如下的一段脚本注入后，就会获取用户的Cookie
    <script language=”javascript”>
          var cockieInfo =window.cockie;
          //send cockieInfo to luminji
    </javascript>

实际案例

使用Fiddler，查看到某系统添加公共信息有一处Post，我们伪造如下的请求：

POST xxx.com/AddPublicInfo HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Content-Type: application/json; charset=utf-8
Accept-Encoding: gzip, deflate
Host: 192.168.80.136
Content-Length: 187
Cookie: ASP.NET_SessionId=qk1qvprjrikp2peveg2ini45; LanguageKey=zh_cn; LoginId=dean;

{"type":"ExtBulletin","title":"1111asdf11","content":"22sdfs22<script>alert(/xss/);</script>","validPeriod":"1","beginDate":"","endDate":"","language":"None","linkFile":"0","fileName":""}

然后，刷新公共信息页面，发现注入代码成功。如果该站点同时存在会话劫持方法的漏洞，则将注入脚本改称获取cookie，攻击者就可以伪造任意访问了本信息的用户来登录系统。

通过该例子我们也可以看到，对于XSS的防范，所有的处理应该是在服务器端的，因为客户端的验证，如使用JS来验证输入是完全可以通过伪造请求被绕过的。所以在安全架构方面对于JS脚本的定位为：JS仅用于改善用户体验。

应对策略

1. 在服务器段限制输入格式,输入类型，输入长度以及输入字符

要注意避免使用一些有潜在危险的html标签，这些标签很容易嵌入一些恶意网页代码。如<img> <iframe><script><frameset><embed><object>< style>等。

注意，不要仅仅在客户端使用js代码加以验证。因为客户端的js脚本可以被绕过。

2. 格式化输出。将输入的内容通过HttpUtility.HtmlEncode处理，这样就不能直接看出输出的内容。

3：对于asp.net站点，可以确保：

注意，默认情况下为true。

4：IE本身也有机制阻止跨站脚本

存在跨站脚本威胁，如果使用的IE8，则这个请求会被拦截，提示“Internet Explorer 已对此页面进行了修改，以帮助阻止跨站脚本。单击此处，获取详细信息...”。

这个错误是由于 IE8 的跨站脚本(Cross-site scripting, XSS)防护阻止了跨站发送的请求。

以下是如何配置它：点击 IE8 的“工具”-“Internet 选项”，进入“安全”选项卡，打开“Internet”下方的“自定义级别”，在“安全设置”对话框中找到“启用 XSS 筛选器”，改为“禁用”即可。注意，“启用”是默认配置。

当然，浏览器本身的这种机制是不可靠的。

具体措施

n 查找所有code behind中的”.Text”

通过文件查找出所有的为文本赋值的代码行；

n 为赋值Encode

对上一步骤查找出来的赋值，首先Encode。

n 查找所有的WCF方法中返回字符串的

通过文件查找”.svc”，找到全部的WCF方法，筛选出返回string的方法

n 处理字符串再返回

对上一步骤查找出来的返回的string，先找到序列化方法，然后对实体的可能被用于输出为html的属性，首先Encode

以上统计纳入到如下表格：

序号	文件	代码行	处理完成否

n 查找所有的文本输入控件

通过文件查找前台所有的””text””,”’text’”,”type=text”,”textarea”,”textbox”字样，筛选出含文本输入的控件，这些控件包括：

<asp:TextBox runat="server"></asp:TextBox>

n 查找所有带参数的URL

通过文件查找所有的”aspx?”,”html?”,”htm?”,”.svc”（随系统的文件后缀方案而定），筛选出所有带参数的URL。

n 查找所有的ajax

通过文件查找前台中所有的”ajax”，筛选出所有的ajax输入。

n 查找所有cookie

通过文件查找所有的”cookie”，找出所有设置cookie的地方。

n 查找所有session

通过文件查找所有的” session”，找出所有设置session的地方。

n 处理以上查找的结果

分别将其对应的输出查找出来，然后汇集为如下的表格：

序号	前台文件	输入出代码行	输出文件	为输出赋值的代码行	处理完成否

n 查找遗漏

为了防止遗漏，需要直接查找输出，通过文件查找所有的”Response.Write”（后台）,” innerHTML”（前台）,”document.write”（前台）。将遗漏更新到上面的表格中。

注意，实际上，如果将应用程序变量和数据库内容赋值给前台控件，通过这种方式还是不能找到遗漏的，只能依赖于前面的输入的查找来一定程度上避免这种情况。

n 根据以下表格中的处理方法来处理上面统计出来的表格中的代码行，为输出Encode

为了防范XSS攻击，我们可以使用Anti-Cross Site Scripting Library（查看http://msdn.microsoft.com/en-us/library/aa973813.aspx，不过当前版本已经到了4.2.1，下载地址为：http://www.microsoft.com/en-us/download/details.aspx?id=28589）

该Library提供如下的几个函数，分别对不同的应用场景作出处理：

Encoding Method	Should Be Used If …	Example/Pattern
HtmlEncode	Untrusted input is used in HTML output except when assigning to an HTML attribute.	<a href="http://www.contoso.com">Click Here [Untrusted input]</a>
HtmlAttributeEncode	Untrusted input is used as an HTML attribute	<hr noshade size=[Untrusted input]>
JavaScriptEncode	Untrusted input is used within a JavaScript context	<script type="text/javascript"> … [Untrusted input] … </script>
UrlEncode	Untrusted input is used in a URL (such as a value in a querystring)	<a href="http://search.msn.com/results.aspx?q=[Untrusted-input]">Click Here!</a>
VisualBasicScriptEncode	Untrusted input is used within a Visual Basic Script context	<script type="text/vbscript" language="vbscript"> … [Untrusted input] … </script>
XmlEncode	Untrusted input is used in XML output, except when assigning to an XML attribute	<xml_tag>[Untrusted input]</xml_tag>
XmlAttributeEncode	Untrusted input is used as an XML attribute	<xml_tag attribute=[Untrusted input]>Some Text</xml_tag>

n 确保配置web.config中的validateRequest="true"

n 确保Cookie的httponly

通过文件查找所有的”cookie”，找出所有设置cookie的地方，为用于认证的cookie设置如下的格式：

Set-Cookie: cookieName=cookieValue;httponly

参考:

http://msdn.microsoft.com/en-us/library/ff649310.aspx

http://msdn.microsoft.com/en-us/library/aa973813.aspx

本文链接

ASP.NET性能优化之负载均衡

2012-05-16T00:55:00Z

1：HTTP重定向

所谓HTTP重定向，就是通过修改HTTP响应头中的Location标识为新的URL，然后返回给客户端，让客户端重新根据这个Location标识的URL去做新的请求。

这是一种最简单、也是最轻量级的负载均衡实现方案，使用asp.net，我们可以这样来实现，比如在主站www.yourdomain.com中，我们在默认主页如下编码：

static string[] servers =
{
"http://192.168.0.77/luminji2/aspx/test3.aspx",
"http://192.168.0.77/luminji2/aspx/test4.aspx"
};
protected void Page_Load(object sender, EventArgs e)
{
Response.Redirect(servers[DateTime.Now.Millisecond % 2]);
}

在上面的代码中，Response.Redirect实际为http头返回状态码302，这是为了告诉浏览器，请到Location中去拿URL，并且去到这个新的URL去做请求。当然，我们也可以采用最原始的方法来代替Redirect方法：

Response.Status = "302 Found";
Response.StatusCode = 302;
Response.AddHeader("Location", servers[DateTime.Now.Millisecond % 2]);

使用HttpWatch监视，我们对www.yourdomain.com请求，得到：

可以清晰的看到第一次请求返回的302，然后转发到新的地址，得到状态码200。

以上方法是在客户端的重定向，即浏览器请求了两次，一次是到主服务器，第二次是到Location中指定的服务器上去请求。

HTTP重定向的方式非常依赖于主站的处理能力，它的性能瓶颈也是来自于IIS对于接受请求->asp.net处理首页动态程序->返回带有特定头请求，是的，它不能突破自身的性能瓶颈，比如，在我的破测试机上，我得到的吞吐率为：

好在IIS自身已经支持重定向（查阅http://technet.microsoft.com/zh-cn/library/cc732969(WS.10).aspx），这更进一步省略了我们自己写代码实现重定向，省略运行ASP.NET代码带来的性能损耗。

2：varnish实现的反向代理负载均衡

另外一种思路是使用反向代理服务器的负载均衡功能，上篇当中介绍的varnish就支持这样的功能，查看配置文件：

backend web1 {
.host = "192.168.0.77";
.port = "8081";
}
backend web2 {
.host = "192.168.0.77";
.port = "8082";
}
director lb round-robin {
{
.backend = web1;
}
{
.backend = web2;
}
}
sub vcl_recv {
set req.backend = lb;
return (pass);
}

在该配置文件中，我们部署了两台WEB服务器，当然，为了简单期间，我这里是使用了同一台服务器的两个端口。在vcl_recv函数中，varnish定义了负载均衡。

运行varnish之，我们会发现请求被转发到后台服务器了。

3：其它方案

1：DNS负载均衡，通过增加域名A记录来让DNS服务器实现负载均衡。好处是几乎不会碰到性能问题。缺点：要求每个WEB服务器必须有外网地址。一旦某台服务器崩溃，不能及时让DNS修改生效。不能定义自己的转发策略；

2：IP负载均衡，有LVS-NAT，采用iptables，对LINUX内核操作，性能相对于反向代理服务器并没有质的飞跃；IP负载均衡仍旧需要转发请求给实际服务器，同时需要转发实际服务器的响应给用户，所以，它的性能瓶颈来自于NAT服务器的性能及网络带宽；

3：直接路由，有LVS-DR，工作在数据链路层（第二层），要求所有WEB服务器接入外网；负载均衡器负责转发请求给实际服务器，但是它通过修改数据包中的MAC地址，能够做到让实际服务器的响应直接返回给用户，而不用通过负载均衡器，这当然进一步提升了负载均衡的效率；

4：IP隧道，有LVS-TUN，用于不同机房（即不同WAN网段）的负载均衡，原理同LVS-DR；

本文链接

基于Unity的AOP的符合基于角色的访问控制（RBAC）模型的通用权限设计

2012-01-13T09:38:00Z

AOP的特性使得它非常适合用来设计类似权限控制的功能，这是本文的基础，如果想要了解AOP的实现，可以参考《动态织入的AOP实现》。

在基于角色的访问控制（RBAC）中，有三要素：用户、角色、任务（或操作）（User、Role、Task），其稳定性逐渐增强，两个关系，User<->Role、Role<->Task，其中：

User 是日常管理运行时建立
Role 是部署/交付建立
Task 是开发时确定
User<->Role 是日常管理运行时建立
Role<->Task 是部署/交付时建立

在本例中，针对Task和Role，我们设计如下的两个类：

[AttributeUsage(AttributeTargets.All, AllowMultiple = false, Inherited = true)]
public class TaskAttribute: Attribute
{

public TaskAttribute(string taskName, string taskDescription)
{
TaskName = taskName;
TaskDescription = taskDescription;
}

public string TaskName { get; set; }
public string TaskDescription { get; set; }
}

public class Role
{
public string Name { get; set; }
public List<TaskAttribute> Tasks { get; set; }
}

可以看到，Task是继承自Attribute的，源于Task需要和实际的功能接口匹配起来，而Role，则无此需要。

本文演示所需要的权限关系描述如下：

1：系统有4个权限；

2：系统有两个角色，一个叫做Manager，它具有两个权限，另一个角色为Common，它当前不具备任何权限；

以上的关系描述，我们在代码当中模拟如下：

//模拟系统总共有4种权限
public static List<TaskAttribute> Tasks
{
get
{
if (_tasks == null)
{
_tasks = new List<TaskAttribute>()
{
new TaskAttribute("AddItem","增加"),
new TaskAttribute("ModifyItem","修改"),
new TaskAttribute("RemoveItem","删除"),
new TaskAttribute("ListItem","获取列表")
};
}
return _tasks;
}
}

private static List<Role> _roles;

//模拟系统总共有两类角色
//第一类角色Manager，有增加和修改权限
//第二类角色Common，没有任何权限
public static List<Role> Roles
{
get
{
if (_roles == null)
{
_roles = new List<Role>()
{
new Role(){Name = "Manager", Tasks = new List<TaskAttribute>()
{
new TaskAttribute("AddItem","增加"),
new TaskAttribute("ModifyItem","修改")
}},
new Role(){Name = "Common", Tasks = new List<TaskAttribute>()}
};
}
return _roles;
}
}

权限判断在切面部分，简化如下（可以看到是判断当前用户是否具有相关权限）：

public class AuthorityHandler : ICallHandler
{
/// <summary>
/// Invoke order
/// </summary>
public int Order { get; set; }
public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
{
MethodBase mb = input.MethodBase;
object[] attrObj = mb.GetCustomAttributes(typeof(TaskAttribute), false);

if (attrObj == null)
{
throw new ArgumentException("TaskAttribute should be defined with the AuthorityAttribute");
}
else
{
TaskAttribute attr = (TaskAttribute)attrObj[0];
if (!string.IsNullOrEmpty(attr.TaskName))
{
string taskName = attr.TaskName;
//get current user's roles
IEnumerable<Role> currentUserRoles = from p in SampleApp.Roles where p.Name == SampleApp.User.Name select p;
//if match then return;
foreach (Role currentUserRole in currentUserRoles)
{
IEnumerable<TaskAttribute> tasks = from p in currentUserRole.Tasks
where p.TaskName == taskName
select p;
if (tasks.Count() > 0)
{
var retvalue = getNext()(input, getNext);
return retvalue;
}
}
//else throw exception
throw new UnauthorizedAccessException("access denied");
}
}
return null;
}
}

public class AuthorityAttribute : HandlerAttribute
{
public override ICallHandler CreateHandler(IUnityContainer container)
{
return new AuthorityHandler();
}
}

调用方代码：

static void Main() {
var container1 = new UnityContainer()
.AddNewExtension<Interception>()
.RegisterType<IBiz, Biz1>();
container1
.Configure<Interception>()
.SetInterceptorFor<IBiz>(new InterfaceInterceptor());

SampleApp.User = new User() { Name = "Common" };
var sample1 = container1.Resolve<IBiz>();
sample1.AddItem();

Console.ReadKey();
}

可以看到，使用了Unity来进行AOP；

运行效果：

代码下载：权限.rar

本文链接

动态织入的AOP实现

2012-01-10T07:48:00Z

动态织入的AOP实现，有两种方法：

第一类，借助于Remoting命名空间下的几个类，通过获取当前上下文及反射的机制来实现，这需要被AOP的类需要继承自arshalByRefObject或者ContextBoundObject；

第二类，原理是基于动态代理的思想，即在运行时动态构造一个原有类的子类，这样就可以在子类的重载方法中插入额外代码。

这两类方法，都有显著的不足，前者直接要求我们继承固定类，后者呢，除非父类方法被定义为virtual，或者方法定义于某个接口，否则就不能被重载，这就是得“拦截”并不是可以对任意的方法进行的。

动态织入局限于CLR的限制，不能实现对任何方法进行AOP，如果要突破这个限制，只能采用静态织入的方法，静态织入采用。静态织入突破OO设计模式，可以拦截所有的方法甚至构造函数或属性访问器，因为它是直接修改IL。还有，因为它在运行前修改原有程序集，也就基本不存在运行时的性能损失问题了。它的不足，一方面是框架较复杂，实现较麻烦，依赖于对底层的IL指令集的操纵；

一：继承自ContextBoundObject的实现

帮助类：

public class SecurityAspect : IMessageSink
{
internal SecurityAspect(IMessageSink next)
{
_next = next;
}

private IMessageSink _next;

public IMessageSink NextSink
{
get { return _next; }
}

public IMessage SyncProcessMessage(IMessage msg)
{
Preprocess(msg);
IMessage returnMethod = _next.SyncProcessMessage(msg);
return returnMethod;
}

public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink)
{
throw new InvalidOperationException();
}

private void Preprocess(IMessage msg)
{
if (!(msg is IMethodMessage))
return;
IMethodMessage call = msg as IMethodMessage;
Type type = Type.GetType(call.TypeName);
string callStr = type.Name + "." + call.MethodName;
Console.WriteLine("Security validating : {0} for {1}", callStr,
Environment.UserName);
// call some security validating code
}

}

public class SecurityProperty : IContextProperty, IContributeObjectSink
{
public IMessageSink GetObjectSink(MarshalByRefObject o, IMessageSink next)
{
return new SecurityAspect(next);
}

public string Name
{
get { return "SecurityProperty"; }
}
public void Freeze(Context newContext)
{
}
public bool IsNewContextOK(Context newCtx)
{
return true;
}
}

[AttributeUsage(AttributeTargets.All)]
public class SecurityAttribute : ContextAttribute
{
public SecurityAttribute() : base("Security") { }
public override void GetPropertiesForNewContext(IConstructionCallMessage ccm)
{
ccm.ContextProperties.Add(new SecurityProperty());
}
}

调用方：

class Program
{
static void Main(string[] args)
{
SampleClass s = new SampleClass();
s.DoSomething();
}
}

[Security]
[Tracing]
public class SampleClass: ContextBoundObject
{
public void DoSomething()
{
Console.WriteLine("do something");
}
}

二：Virtual方法及接口的实现

帮助类：

public class LogHandler : ICallHandler
{
/// <summary>
/// 执行顺序
/// </summary>
public int Order { get; set; }
public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
{
Console.WriteLine("方法名: {0}", input.MethodBase.Name);
Console.WriteLine("参数:");
for (var i = 0; i < input.Arguments.Count; i++)
{
Console.WriteLine("{0}: {1}", input.Arguments.ParameterName(i), input.Arguments[i]);
}
Console.WriteLine("方法执行前的处理");
var retvalue = getNext()(input, getNext);
Console.WriteLine("方法执行后的处理");
return retvalue;
}
}

public class LogHandlerAttribute : HandlerAttribute
{
public override ICallHandler CreateHandler(IUnityContainer container)
{
return new LogHandler();
}
}

调用方：

public interface ISample
{
[LogHandler]
void DoSomething();
void DoSomethingNoAop();
}

class Sample1 : ISample
{
public void DoSomething()
{
Console.WriteLine("Sample1 do something");
}

public void DoSomethingNoAop()
{
Console.WriteLine("Sample1 do something no aop");
}
}

public class SampleClass
{

[LogHandler]
public virtual void SampleVirtual()
{
Console.WriteLine("Virtual method");
}

public void Sample()
{
Console.WriteLine("Sampe method");
}
}

class Program {

static void Main() {
//针对接口
var container1 = new UnityContainer()
.AddNewExtension<Interception>()
.RegisterType<ISample, Sample1>();
container1
.Configure<Interception>()
.SetInterceptorFor<ISample>(new InterfaceInterceptor());
container1
.Configure<Interception>()
.SetInterceptorFor<SampleClass>(new VirtualMethodInterceptor());
var sample1 = container1.Resolve<ISample>();
sample1.DoSomething();
sample1.DoSomethingNoAop();

//针对虚拟方法
var sample2 = container1.Resolve<SampleClass>();
sample2.SampleVirtual();
sample2.Sample();

Console.ReadKey();
}

}

可以看到，第二种方法是用Unity实现的，关于Unity，这里多说两句：

Unity的AOP可以从3种标记的情况拦截：
TransparentProxyInterceptor：直接在类的方法上进行标记，但是这个类必须继承MarshalByRefObject；
VirtualMethod：直接在类的虚方法上进行标记，如上文代码；
InterfaceInterceptor：在接口的方法上进行标记，如上文代码；

代码下载：ConsoleApplication1.rar，ConsoleApplication2.rar

本文链接

MVC TIP8：为控制器增加有参构造函数（为了注入等其它用途）

2011-12-22T10:04:00Z

控制器本身是不带有参的构造函数的，如果我们为控制器仅仅提供有参的构造函数，就会报错。不过，可以利用DependencyResolver的SetResolver方法，让ASP.NET MVC支持有参的构造函数。

1：为系统准备两个类型，如下：

注意，这里要实现的是让控制器支持Unity注入。

UnityControllerFactory代码如下：

public class UnityControllerFactory : DefaultControllerFactory
{
IUnityContainer container;
public UnityControllerFactory(IUnityContainer container)
{
this.container = container;
}

protected override IController GetControllerInstance(RequestContext reqContext,
Type controllerType)
{
if (controllerType == null)
{
return null;
}
return container.Resolve(controllerType) as IController;
}
}

UnityDependencyResolver代码如下：

public class UnityDependencyResolver : IDependencyResolver
{
IUnityContainer container;

public UnityDependencyResolver(IUnityContainer container)
{
this.container = container;
}

public object GetService(Type serviceType)
{
if (!this.container.IsRegistered(serviceType))
{
return null;
}
return container.Resolve(serviceType);
}

public IEnumerable<object> GetServices(Type serviceType)
{
return container.ResolveAll(serviceType);
}
}

2：在Application_Start中注册

代码如下：

using (IUnityContainer container = new UnityContainer())
{
UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
section.Configure(container, "containerOne");
//tell mvc use UnityDependencyResolver to create controll instances;
container.RegisterType<IControllerFactory, UnityControllerFactory>();
//_container.RegisterType<ISubjectRepository, SubjectRepository>(new TransientLifetimeManager());
DependencyResolver.SetResolver(new UnityDependencyResolver(container));
}

3：Web.config配置如下

至此，完成本文所述功能。

本文链接

最精简领域驱动设计开发模版（针对WPF）

2011-12-16T07:57:00Z

一：领域驱动中的分层

领域驱动设计将软件系统分为四层：基础结构层、领域层、应用层和表现层。

· 基础结构层：该层专为其它各层提供技术框架支持。注意，这部分内容不会涉及任何业务知识。众所周知的数据访问的内容，也被放在了该层当中，因为数据的读写是业务无关的。

· 领域层：包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。这部分内容的具体表现形式就是领域模型（Domain Model）。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。

· 应用层：该层不包含任何领域逻辑，但它会对任务进行协调，并可以维护应用程序的状态，因此，它更注重流程性的东西。

· 表现层：这个好理解，跟三层里的表现层意思差不多，但请注意，“Web服务”虽然是服务，但它是表现层的东西

从上图还可以看到，表现层与应用层之间是通过数据传输对象（DTO）进行交互的，数据传输对象是没有行为的POCO对象，它的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为何不能直接将领域对象用于数据传递？因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样做会直接将领域对象的行为暴露给表现层。

（在本例中，为了简便期间，用了领域模型，而不是DTO，DTO可以放在基础结构层）

二：实例分层

可以看到：

基础结构层：SmartCA.Infrastructure，包括了一些最简单的声明和实现，如实体对象工厂接口、数据接口、工作单元接口及实现、数据对象的基类；SmartCA.Infrastructure.Repositories，数据访问及实体对象工厂，如果我们换一个数据库，则可以增加第二个Repositories项目；

领域层：领域模型和领域服务在这里；

应用层：在本例子中，应用层只用来存储应用程序的某些状态，不涉及到任何领域领域逻辑；

表现层：无任何特殊；

三：核心类图

该图定义了本实例中的主要类的关系。

需要注意的是，参考资料中是作者实现了一个注入模块的编写，本实例重写了本部分，使用了UNITY来实现注入。

代码下载：SmartCA.rar

参考资料：《领域驱动设计C# 2008实现》

本文链接

Unity TIP4: 带泛型参数的接口注入（interface,generic）

2011-12-15T08:25:00Z

一：第一类需求

接口和类定义如下：

public interface ISample<T>
{}
public class Sample : ISample<SomeClass2>
{}
public class SomeClass2{}

要求用Unity注入。

1：运行时注入

如果是运行时注入，可如下编码：

using (IUnityContainer container = new UnityContainer())
{
ConfigurationManager.GetSection("unity");
UnityConfigurationSection.CurrentSection.Configure(container, "containerOne");
container.RegisterType<ISample<SomeClass2>, Sample>();
var re = container.Resolve<ISample<SomeClass2>>();
}

2：配置文件配置注入

如果是在配置文件中配置，配置文件如下：

编码如下：

using (IUnityContainer container = new UnityContainer())
{
ConfigurationManager.GetSection("unity");
UnityConfigurationSection.CurrentSection.Configure(container, "containerOne");
var re = container.Resolve<ISample<SomeClass2>>("Sample");
}

二：第二类需求

接口和类定义如下：

public interface ISample<T>
{}
public class Sample<T> : ISample<T>
{ }
public class SomeClass2{}

1：运行时注入

如果是运行时注入，可如下编码：

using (IUnityContainer container = new UnityContainer())
{
ConfigurationManager.GetSection("unity");
UnityConfigurationSection.CurrentSection.Configure(container, "containerOne");
container.RegisterType<ISample<SomeClass2>, Sample<SomeClass2>>();
var re = container.Resolve<ISample<SomeClass2>>();
}

2：配置文件配置注入

如果是在配置文件中配置，配置文件如下：

编码如下：

using (IUnityContainer container = new UnityContainer())
{
ConfigurationManager.GetSection("unity");
UnityConfigurationSection.CurrentSection.Configure(container, "containerOne");
var re = container.Resolve<ISample<SomeClass2>>("Sample");
}

三：总结

可以看到，如果是运行时注入，那么Resolve方法中，必须指定泛型的类型。

如果是在配置文件中，为了表明这是个带泛型参数的接口或者类，则需要为其指定后缀“`”。

本文链接

ASP.NET性能优化之分布式Session

2011-11-03T00:56:00Z

如果我们正在使用Session，那么构建高性能可扩展的ASP.NET网站，就必须解决分布式Session的架构，因为单服务器的SESSION处理能力会很快出现性能瓶颈，这类问题也被称之为Session同步。微软有自己的分布式Session的解决方案，那就是SessionStateServer，我们可以参考：

ASP.NET Session State Partitioning
http://blog.maartenballiauw.be/post/2008/01/23/ASPNET-Session-State-Partitioning.aspx

ASP.NET load balancing and ASP.NET state server
http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-(aspnet_state).aspx

不过本文是要换一个方案，那就是使用Memcached来到达分布式SESSION的架构。Memcached作为分布式的缓存服务器已经被广泛应用在网站建设中。

一：Session的机制

Session是针对用户的，我们也可以理解为是针对浏览器的。在浏览器首次访问ASP.NET网页的时候（网页没有关闭session功能），它会发送如下的HTTP头给客户端：

浏览器在收到上面的HTTP头后，会将这个唯一的SESSIONID保存在自己的COOKIE中（只要没有禁用COOKIE，本文不讨论禁用COOKIE的案例，可参考本博文http://www.cnblogs.com/fish-li/archive/2011/07/31/2123191.html，写的很NICE）。当浏览器再次请求服务器进行访问的时候，它会在请求HTTP头中加入如下的标识，我们可以看到，这个SESSIONID就是上面的SESSIONID：

浏览器和服务器间就是通过这样一种机制来确保用户SESSION的。

如果客户端浏览器禁用了Cookie会怎么样，我们会发现每一次刷新浏览器Set-Cookie都是不同的，而发送请求头中也永远不会出现Cookie标识。这个时候，我们会发现Session失效了（当然，微软为了防止出现这种情况，允许我们在sessionState中设置cookieless="true"，用URL来传递sessionid）。

二：Memcached Providers

我使用的Memcached客户端是Memcached Providers，下载完毕后，你会发现Memcached Providers已经提供了对分布式Session的支持功能。如果你还不会使用Memcached Providers，请参考此文Memcached Tip 1：使用Memcached Providers。Memcached Providers提供的示例是直接将SESSION存储在数据库，我们可以通过配置来将SESSION支持存储在分布式SESSION的内存中，即，将下文中的dbType由SQL修改为none。：

使用Memcached Providers提供的分布式Session没有任何特别之处，因为Memcached Providers提供的SessionStateProvider类型实现的是ASP.NET中的SessionStateStoreProviderBase这个抽象类，我们可以看到配置文件中指定了Session的处理类是SessionStateProvider，所以，ASP.NET在接受到客户端的请求后，会自觉滴使用SessionStateProvider来处理所有的SESSION，也正是这个类，完成了将SESSION读取和存储在Memcached中（如果设置了SQL，则会同步存储到SQLSERVER数据库）。

SESSION的设置和读取与传统没有任何区别，读：

Session["sname2"] = "sluminjxxi";
Session.Timeout = 2;

取：

Response.Write(Session["sname2"]);

三：为什么要配置SQL

传统的SESSION的缺点，在仅使用dbType为none配置的时候都会存在。如Memcached的内存到达上限的时候会怎么办？Memcached使用LRU淘汰算法（最久未使用），在这里我们不需要去细究这个算法在Memcached内部到底是什么样一个机制，我们只需要知道，在内存紧张的时候，即使SESSION时间未到，Memcached也有可能把它干掉。所以，保险的做法是，在Memcached之下，再加上SQLSERVER的持久化保存。如果缓存命中的，直接取缓存，如果缓存没命中的，则再到数据库中确认一次。当然，这样会带来一些性能损耗，但是却是更安全的做法。

Memcached Providers提供的下载文件中，提供了初始化SESSION的一些脚本，正确执行后，它会生成如下一个表tblSessions，及若干存储过程：

tblSessions保存的是就是单独的Session，如下：

四：Memcached Providers的一个BUG

在当前的Memcached Providers（1.2版本）中关于SessionStateProvider（29520-TRUNK）是有一个BUG（我已提交到codeplex，相信他们的下一个版本应该能得到修正）的。如果我们测试SESSION失效时间，发现只要经过一次刷新后，就永远是20分钟（即默认）。这源于在ReleaseItemExclusive这个重载方法中（该方法用于释放对会话数据存储区中项的锁定），对于Session的重新存储没有加上过期时间，如下：

注释掉的是Memcached Providers提供的源码，而正确的应该是我修正过的上一条。使用修正过的DLL，一切圆满了。

五：采用数据库存储SESSION的可扩展问题

随着访问量的进一步上升（当然，到了这种程度，说明网站做的很很成功，绝大部分的网站是不需要考虑这一步的），即便我们使用了Memcached作缓存，使用单一的SQLSERVER存储SESSION仍旧带来了性能问题，在这种情况下，我们对于数据库的设计可以采用水平分区的架构，即根据某种算法（可以根据SESSIONID，或者用户名等）将SESSION存储到不同的数据库中。这个时候，如果我们仍旧使用Memcached Providers，那么必须进一步修改源码了，由原先支持单一SQLSERVER服务器，编程支持多个服务器。当然，如果不喜欢SQLSERVER，还可以修改为支持mysql、mongodb、任何自定义的KEY-VALUE框架等等，此为后话，暂且不表。

本系列的前篇：

1：ASP.NET性能优化之构建自定义文件缓存

2：ASP.NET性能优化之让浏览器缓存动态网页

3：ASP.NET性能优化之减少请求

4：ASP.NET性能优化之反向代理缓存

5：ASP.NET性能优化之局部缓存

本文首发于AgileSharp-创业互推平台

本文链接

ASP.NET性能优化之局部缓存

2011-10-19T01:27:00Z

在网站的开发过程中，经常碰到的一类需求场景是：

1：页面含热点新闻，热点新闻部分需要10分钟更新一次，而整个页面的其它部分1天内都不会变动；

2：首页的某个BANNER需要显式：欢迎***；

上面场景中的1，如果整个页面的缓存失效都定为10分钟，则势必增加性能开销，所以最好的策略是页面的不同部分采用不同的缓存失效时长。对于场景2也一样，我们不应该为了迁就某个BANNER不能应用缓存，就让整个页面都不支持缓存。

可以说，如果我们在开发网站过程中的缓存策略是不支持页面局部缓存的，整个架构就是不合理的。

一：局部缓存常用解决方案

针对上面的需求，有几类解决方案：

1、Client Side Includes(CSI)：通过frame、iframe、 javascript、javacript+ajax等方式将另外一个页面的内容动态包含进来。像现在流行的jquery等javascript库对此有较好的支持。

优点：能够利用浏览器客户端并行处理及装载的机制；通过浏览器缓存机制可以降低网络传输时间，提高性能；计算放在客户端，能够降低服务器端压力

缺点：搜索引擎优化问题；javascript兼容性问题；客户端缓存可能导致服务器端内容更新后不能及时生效；XSS等安全隐患

2、Server Side Includes(SSI)：

优点：SSI技术是通用技术，不受具体语言限制，只需要Web服务器或应用服务器支持即可，Ngnix、Apache、Tomcat、Jboss等对此都有较好的支持

缺点：SSI在语法上不能够直接包含其他服务器的url（当然也可以通过redirect等来变通实现），因此在需要充分利用缓存及负载均衡的环境下相对不是很灵活。

当然如果不使用单独的缓存服务器，而是使用Ngnix，利用Ngnix对SSI及Memcached支持，通过NginxHttpSsiModule、 NginxHttpMemcachedModule也可以实现页面缓存，但与专业的缓存服务器（例如Varnish）相比较，Ngnix作为缓存服务器只适合于中小规模的场合。

3、使用ASP.NET的片段缓存

可以利用用户控件将页面分段，在ascx文件中写入缓存的语句，而不在aspx文件中写缓存语句，这样ASP.NET就可以只缓存ascx片断的输出了。

缺点：片段缓存不支持Location特性；缓存页面片段惟一合法的地方是web服务器。这是因为片段缓存在ASP.NET中是新的功能，所以浏览器和代理服务器不支持。由于它不是W3C标准，像SQUID和VARNISH这样的代理服务器也不支持它。

4、Edge Side Includes (ESI)：

Edge Side Includes(ESI) 和Server Side Includes(SSI) 和功能类似。SSI需要特殊的文件后缀(shtml,inc)。ESI可以直接通过URI包含远程服务器文件，ESI更适合用于缓存服务器上，缓存整个页面或页面片段，因此ESI特别适合用于缓存。本文要介绍的就是ESI的方式来支持局部缓存。

优点：ESI是一个W3C标准，被当下流行的缓存服务器SQUID，Varnish支持。

二：ESI的ASP.NET实现

本文所要阐述的是ESI局部缓存的实现。主页面（test1.aspx）前台：

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="test1.aspx.cs" Inherits="WebApplication2.aspx.test1" %>

<%@ Import Namespace="System.Globalization" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
</head>
<body>
<div>这里是局部缓存</div>
<esi:include src="test2.aspx"/>
<div>局部缓存结束</div>
<%=DateTime.Now.ToString("U", DateTimeFormatInfo.InvariantInfo)%>
</body>
</html>

主页面的后台请参看上篇，对主页面采取了缓存策略，即在页面中使用esi:include标识。

被包含的页面（test2.aspx）的前台：

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="test2.aspx.cs" Inherits="WebApplication2.aspx.test2" %>

<%@ Import Namespace="System.Globalization" %>
<div>
局部缓存中的页面：
<%=DateTime.Now.ToString("U", DateTimeFormatInfo.InvariantInfo)%>
</div>

被包含的页面的后台什么也不需要处理，也就是不为它加入任何缓存策略，该页面是实时的。

VARNISH配置文件如下：

backend default {
.host = "192.168.0.77";
.port = "80";
}
sub vcl_fetch {
remove beresp.http.Set-Cookie;
if(req.url ~ "test1.aspx") {
esi;
}
if(req.url ~ "test2.aspx"){
return (pass);
}
}
sub vcl_recv {
remove req.http.Cookie;
#remove req.http.Accept-Encoding;
#remove req.http.Vary;
}
sub vcl_hit {
if(req.http.Cache-Control~"no-cache"||req.http.Cache-Control~"max-age=0"||req.http.Pragma~"no-cache"){
set obj.ttl=0s;
return (restart);
}
return (deliver);
}
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
} else {
set resp.http.X-Cache = "MISS";
}
}

上文的vcl_fetch函数中加了两个判断，指的是：如果碰到test1.aspx就处理esi标识，如果碰到test2.aspx，就直接忽略让后台IIS处理。

值得注意的是，启动命令中加入了-p选项（这是一个varnish的小问题，请查阅参考，此处不表）：

varnishd -a :8011 -T :8088 -f c:/varnish/etc/default.vcl -p esi_syntax=0x1 -s file,c:/varnish/var/cache,100M

三：效果

启动varnish后，我们发现，对于test2.aspx，由于我们使用了esi对其进行了包含，而test2.aspx又未进行缓存，所以在test1.aspx的缓存有效期内，随着每一次刷新，test1.aspx的内容没有变动，但是所包含的test2.aspx区域，会实时刷新。

参考（第一小节大部分来自参考文字）：

https://www.varnish-cache.org/trac/ticket/352

http://cd34.com/blog/infrastructure/no-esi-processing-first-char-not/

http://hi.baidu.com/chuanliang2007/blog/item/075f67963e20f315d31b7035.html

http://www.w3.org/TR/esi-lang

本系列的前篇：

1：ASP.NET性能优化之构建自定义文件缓存

2：ASP.NET性能优化之让浏览器缓存动态网页

3：ASP.NET性能优化之减少请求

4：ASP.NET性能优化之反向代理缓存

本文首发于AgileSharp-创业互推平台

本文链接