1.使用Forms验证存储用户自定义信息

Forms验证在内部的机制为把用户数据加密后保存在一个基于cookie的票据FormsAuthenticationTicket中，因为是经过特殊加密的，所以应该来说是比较安全的。而.net除了用这个票据存放自己的信息外，还留了一个地给用户自由支配，这就是现在要说的UserData。

UserData可以用来存储string类型的信息，并且也享受Forms验证提供的加密保护，当我们需要这些信息时，也可以通过简单的get方法得到，兼顾了安全性和易用性，用来保存一些必须的敏感信息还是很有用的。

下面来看怎么使用UserData，然后会给出一个实际使用的例子。

//创建一个新的票据，将客户ip记入ticket的userdata
FormsAuthenticationTicket ticket=new FormsAuthenticationTicket(
1,userName.Text,DateTime.Now,DateTime.Now.AddMinutes(30),
false,Request.UserHostAddress);
//将票据加密
string authTicket=FormsAuthentication.Encrypt(ticket);
//将加密后的票据保存为cookie
HttpCookie coo=new HttpCookie(FormsAuthentication.FormsCookieName,authTicket);
//使用加入了userdata的新cookie
Response.Cookies.Add(coo);

下面是FormsAuthenticationTicket构造函数的重载之一的方法签名
public FormsAuthenticationTicket(
int version,
string name,
DateTime issueDate,
DateTime expiration,
bool isPersistent,
string userData
);

参数
version
版本号。
name
与身份验证票关联的用户名。
issueDate
Cookie 的发出时间。
expiration
Cookie 的到期日期。
isPersistent
如果 Cookie 是持久的，为 true；否则为 false。
userData
将存储在 Cookie 中的用户定义数据

使用userdata也很简单，FormsIdentity的Ticket属性就提供了对当前票据的访问，获得票据后就可以用UserData属性访问保存的信息，当然是经过解密的。
((System.Web.Security.FormsIdentity)this.Context.User.Identity).Ticket.UserData


下面是一个具体的应用。

由于Forms验证是通过cookie来进行的，它需要传递一个票据来进行工作。虽然票据是加密的，里面的内容不可见，但这并不能阻止别人用一个假冒的身份使用票据（就像我们可以拿别人的钥匙去开别人的锁），比较常见的就是不同ip的用户在不安全通道截获了这个票据，然后使用它进行一些安全范围外的活动。

解决这个问题的办法之一就是使用SSL来传递信息。

但是如果不能使用SSL呢？我们可以判断ip和票据是否匹配，如果发出请求的ip是初次产生票据的ip，则没有问题，否则就销毁这个票据。

为此，我们需要在一开始处理登录时将用户的ip保存起来，这样就可以在以后的请求中随时验证后继请求的ip是否和初始ip相同。保存这个敏感ip的最佳场所当然是UserData啦，而验证的时机则是在AuthenticateRequest事件发生时，即Global.aspx.cs中定义的处理此事件的Application_AuthenticateRequest方法中。

上面的示例实际上已经是把用户ip保存到了UserData中，下面是验证的过程。

if(this.Request.IsAuthenticated)
{
if(((System.Web.Security.FormsIdentity)this.Context.User.Identity).Ticket.UserData !=this.Request.UserHostAddress)
{
System.Security.Principal.GenericIdentity gi=new System.Security.Principal.GenericIdentity("","");
string[] rolesi={};
System.Security.Principal.GenericPrincipal gpi=new System.Security.Principal.GenericPrincipal(gi,rolesi);
this.Context.User=gpi;
}
}

通过给GenericPrincipal空的GenericIdentity和roles使票据失效，这样将强迫用户重新登录。为了测试这个方法，可以先把条件改为相等，看效果如何 ：）

这个方法也有不足之处，具体为：

1.使用同一代理的用户将拥有同一个ip，这样就不能防范此类假冒攻击了

2.如果用户使用动态ip，则可能造成正常用户被我们强行销毁票据。不过总的来说，这个办法还是比较可行的。


2.使用安全特性配合Forms验证进行安全操作。

PrincipalPermissionAttribute可以配合Forms验证进行基于角色或用户的安全验证，该特性不能用于程序集级别。它的作用范围可以是类或具体的方法。来看一个简单的示例。

[PrincipalPermission(SecurityAction.Demand,User="Notus")]
public class Test : BasePage
{
private void Page_Load(object sender, System.EventArgs e)
{
try
{
this.sayHello();
this.sayHello2();
}
catch(Exception ex)
{
Response.Write(ex.ToString());
}
}

private void sayHello()
{
Response.Write("hello world!");
}

private void sayHello2()
{
Response.Write("hello PrincipalPermissionAttribute!");
}



#region Web 窗体设计器生成的代码
override protected void OnInit(EventArgs e)
{
//
// CODEGEN: 该调用是 ASP.NET Web 窗体设计器所必需的。
//
InitializeComponent();
base.OnInit(e);
}

/// <summary>
/// 设计器支持所需的方法 - 不要使用代码编辑器修改
/// 此方法的内容。
/// </summary>
private void InitializeComponent()
{
this.Load += new System.EventHandler(this.Page_Load);
}
#endregion

}


注意这个例子一开始是作用于整个类的，生成后执行，如果当前用户不是Notus，就会发生异常System.Security.SecurityException，提示对主体权限的请求失败。反之，则可以顺利访问，并输出两个hello world!，注意是两个。现在的安全作用范围是整个类。

接下来我们改一下特性的作用范围。将特性声明移到sayHello2方法上面，重新编译后运行，就会发现程序在运行到sayHello2方法后抛出了Sy