FormsAuthenticationTicket的问题请教
[问题点数：100分，结帖人westqy]
FormsAuthenticationTicket的问题请教
[问题点数：100分，结帖人westqy]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2008年8月 .NET技术大版内专家分月排行榜第一
2008年6月 .NET技术大版内专家分月排行榜第二
2008年8月 .NET技术大版内专家分月排行榜第一
2008年6月 .NET技术大版内专家分月排行榜第二
2010年 总版技术专家分年内排行榜第一2009年 总版技术专家分年内排行榜第一
2011年 总版技术专家分年内排行榜第二
2008年8月 .NET技术大版内专家分月排行榜第一
2008年6月 .NET技术大版内专家分月排行榜第二
2008年8月 .NET技术大版内专家分月排行榜第一
2008年6月 .NET技术大版内专家分月排行榜第二
2008年8月 .NET技术大版内专家分月排行榜第一
2008年6月 .NET技术大版内专家分月排行榜第二
本帖子已过去太久远了，不再提供回复功能。今天看啥 热点：
FormsAuthenticationTicket session、cookies为3种常用的验证用户登陆的方法，下边说一下他们的区别：
1）FormsAuthenticationTicket 是。net framework2.0及其以上版本中固有的验证机制，其本质是把用户的cookies信息加密存储在客户端，这样可以部分降低服务器端的内存消耗，不必像session那样把用户信息存储在服务端内存当中，而其数据的安全性则有微软来保证,详细用法请参考msdn官方文档：/zh-cn/library/system.web.security.formsauthenticationticket_members(v=vs.80).aspx。
2）session 使用session存储用户信息使用发放简便，可在含有http上下文的任意位置添加session对象，并且可以把对象赋予session，因为session为object类型，可被任意对象赋值，session本质上其实是在服务器端内存中开辟一段存储区用于存放session的值，而在客服端浏览器）留下一个cookies标记，该标记为服务器端的session的一个id，不是session对象的具体内容，这样相对于数据安全来说相对安全，但也只是相对，这样做会对服务器端内存有所消耗，但影响应该不是很大，除非你的网站同时在线人数很多。不过session机制还是有一些缺陷，iisIIS重启也会造成Session丢失。这样用户就要重新登录或者重新添加购物车、验证码等放到Session中的信息。所以微软才推荐使用FormsAuthenticationTicket票据方式来验证用户登陆。
3）cookies 以上2种方式都间接的使用了cookies，使用cookies来验证用户身份时，记得最好加密一下，除非你设定cookies的过期的时间，不然还是很容易被黑客所利用，造成不必要的用户信息泄露。但cookies存储数据的大小有限制，平均下来不超过4K，有的浏览器支撑比较高，但那也只是有的不是所有浏览器都是，咱们只能取最小值。
以上只是本人的拙见，不对之处希望大家给予指教，共同进步650) this.width=650;" border="0" alt="" src="/uploads/allimg/IK044-0.gif" width="19" height="19" />
&本文出自 “跃跃欲试的鱼” 博客，谢绝转载！
相关搜索：
相关阅读：
相关频道：
&&&&&&&&&&&&&&&&
Asp.Net教程最近更新CAS总结之Ticket篇(转,非常详细，后文还提到一个ppt，非常易懂) - 博客频道 - CSDN.NET
99%的努力换不来100%的成功
分类：单点登录
CAS的核心就是其Ticket，及其在Ticket之上的一系列处理操作。CAS的主要票据有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0协议中就有的票据，PGT、PGTIOU、PT是CAS2.0协议中有的票据。
一 名词解释
TGT（Ticket Grangting Ticket）
TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成cookie，写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。
ST（Service Ticket）
ST是CAS为用户签发的访问某一service的票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。
PGT（Proxy Granting Ticket）
Proxy Service的代理凭据。用户通过CAS成功登录某一Proxy Service后，CAS生成一个PGT对象，缓存在CAS本地，同时将PGT的值（一个UUID字符串）回传给Proxy Service，并保存在Proxy Service里。Proxy Service拿到PGT后，就可以为Target Service（back-end service）做代理，为其申请PT。
PGTIOU（Proxy Granting Ticket IOU）
PGTIOU是CAS协议中定义的一种附加票据，它增强了传输、获取PGT的安全性。
PGT的传输与获取的过程：Proxy Service调用CAS的serviceValidate接口验证ST成功后，CAS首先会访问pgtUrl指向的https url，将生成的 PGT及PGTIOU传输给proxy service，proxy service会以PGTIOU为key，PGT为value，将其存储在Map中；然后CAS会生成验证ST成功的xml消息，返回给Proxy Service，xml消息中含有PGTIOU，proxy service收到Xml消息后，会从中解析出PGTIOU的值，然后以其为key，在map中找出PGT的值，赋值给代表用户信息的Assertion对象的pgtId，同时在map中将其删除。
PT（Proxy Ticket）
PT是用户访问Target Service（back-end service）的票据。如果用户访问的是一个Web应用，则Web应用会要求浏览器提供ST，浏览器就会用cookie去CAS获取一个ST，然后就可以访问这个Web应用了。如果用户访问的不是一个Web应用，而是一个C/S结构的应用，因为C/S结构的应用得不到cookie，所以用户不能自己去CAS获取ST，而是通过访问proxy service的接口，凭借proxy service的PGT去获取一个PT，然后才能访问到此应用。
二 代码解析
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& CAS Ticket类图
TicketGrantingTicket 的 grantServiceTicket方法
方法声明：public synchronized ServiceTicket grantServiceTicket(final String id,final Service service, final ExpirationPolicy expirationPolicy, final boolean credentialsProvided)
&1：生成SerivceTicketImpl
&2：更新属性：
this.previousLastTimeUsed = this.lastTimeU
&& this.lastTimeUsed = System.currentTimeMillis();
&& this.countOfUses++;
&3：给service对象的principal属性赋值
&4：将service对象放入map services
ServiceTicket 的 grantTicketGrantingTicket方法
方法声明：
public TicketGrantingTicket grantTicketGrantingTicket(final String id, final Authentication authentication,final ExpirationPolicy expirationPolicy)
方法描述：在CAS3.3对CAS2.0协议的实现中，PGT是由ST签发的，调用的就是ServiceTicket的grantTicketGrantingTicket方法。方法返回的TicketGrantingTicket对象，表征的是一个PGT对象，其中的ticketGrantingTicket属性的值是签发ST的TGT对象。
TicketGrantingTicket 的 expire方法
方法声明：void expire()
方法描述：
在CAS的logout接口实现中，要调用TGT对象的expire方法，然后会在缓存中清除此TGT对象。
expire方法的内容：循环遍历 services 中的Service对象，调用其logoutOfService方法。具体Service实现类中的logoutOfService方法的实现，要通知具体的应用，客户要退出。
TGT、ST、PGT、PT之间关系的总结
1：ST是TGT签发的。用户在CAS上认证成功后，CAS生成TGT，用TGT签发一个ST，ST的ticketGrantingTicket属性值是TGT对象，然后把ST的值redirect到客户应用。
2：PGT是ST签发的。用户凭借ST去访问Proxy service，Proxy service去CAS验证ST（同时传递PgtUrl参数给CAS），如果ST验证成功，则CAS用ST签发一个PGT，PGT对象里的ticketGrantingTicket是签发ST的TGT对象。
3：PT是PGT签发的。Proxy service代理back-end service去CAS获取PT的时候，CAS根据传来的pgt参数，获取到PGT对象，然后调用其grantServiceTicket方法，生成一个PT对象。
& & & & & & & & & & & & & & & & & & & & TGT、ST、PGT、PT之间的关联关系
注：如果本文中介绍的&Ticket&概念不详细，请参考本人的另一篇文章&CAS&总结之协议分析篇()，里面的动画演示比较清楚地表达了&Client&、&Service&、&CAS&三者之间的交互。
CAS是怎么操作的呢?或则是KRB(Kerberos)怎么操作的呢?
他并不是很复杂,他先是建立一个 专门认证用户的 服务(SERVER) 这个服务只做一件事,负责验证用户的ID和PASS 是否是正确,在正确的情况提供用户一个名为TGT的票据,
相当你要去游乐场玩,首先你要在门口检查你的身份(即CHECK 你的ID和PASS),如果你通过验证,游乐场的门卫(AS)即提供给你一张门卡(TGT).
这张卡片的用处就是告诉 游乐场的各个场所,你是通过正门进来,而不是后门偷爬进来的,并且也是获取进入场所一把钥匙.
好的,现在你有张卡,但是这对你来不重要,因为你来游乐场不是为了拿这张卡的,好的,我们向你的目的出发, 恩,你来到一个摩天楼,你想进入玩玩,
这时摩天轮的服务员(client)拦下你,向你要求摩天轮的(ST)票据,你说你只有一个门卡(TGT),好的,那你只要把TGT放在一旁的票据授权机(TGS)上刷一下,
票据授权机(TGS)就根据你现在所在的摩天轮,给你一张摩天轮的票据(ST),哈,你有摩天轮的票据, 现在你可以畅通无阻的进入摩天轮里游玩了.
当然如果你玩完摩天轮后,想去游乐园的咖啡厅休息下,那你一样只要带着那张门卡(TGT).到相应的咖啡厅的票据授权机(TGS)刷一下,得到咖啡厅的票据(ST)就可以进入咖啡厅
当你离开游乐场后,想用这张TGT去刷打的回家的费用,呵呵,对不起,你的TGT已经过期了,在你离开游乐场那刻开始,你的TGT就已经销毁了~&
Service ticket(ST)&&--------- 服务票据， 由KDC 的 TGS 发放。 任何一台Workstation 都需要拥有一张有效的 Service Ticket 才能访问域内部的应用(Applications)。&
Ticket Granting tieckt(TGT)&--------- 票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据(ST)便不必再向KDC 提交身份认证信息(准确术语是 Credentials)。&
authentication service (AS)&--------- 认证用服务，索取 Crendential，发放 TGT&
ticket-granting service (TGS)&--------- 票据授权服务，索取 TGT，发放 ST
排名：第5063名
（9）（30）（3）（33）（9）（15）（5）（7）（5）（9）（1）（2）（7）（3）（2）（8）（28）（7）（13）（4）（5）（1）（3）（2）（8）（3）（11）（3）（1）（3）（4）（22）（3）（1）（1）（1）（3）（4）（1）（1）（2）（13）（2）（8）（7）（2）（2）（1）（1）3406人阅读
J2EE（95）
文章只做技术研究 &如果通过此技术违反国家法律，一切后果自负，作者不承担任何责任。
好吧，先来唠叨，唠叨。这几天大家都沉浸在抢票中，当然我也不例外。
最后总结一句，有抢票软件不一定能抢到票，没抢票软件一定是抢不到票，网页一点就死了。
往年，还能弄个小工具抢抢，今年12306换了件新衣服，更加跑不动了，最后独留下孤单在心里。
好吧 ，进入正题：玩转新版12306抢票
订火车票无非是如下几个流程：&
登录 - 查询 - &点预定按钮 - 提交订票用户 - &确认订单 或者是 自动所谓的自动刷票 & 登录 - 查询 - 输入验证码提交
下面一起分析分析这两套流程：
首先准备抓包工具
登录拆分为:
/otn/ &抓cookie
/otn/passcodeNew/getPassCodeNew?module=login&rand=sjrand 获取验证码
/otn/passcodeNew/checkRandCodeAnsyn &预验证验证码
/otn/login/loginAysnSuggest & 登录
/otn/login/userLogin 正式登录(没有这个请求是无法登录的)
查票 & /otn/leftTicket/query?leftTicketDTO.train_date=&leftTicketDTO.from_station=SZQ&leftTicketDTO.to_station=BHQ&purpose_codes=ADULT
注意这个请求的cookie &这个cookie会伴随抢票流程的始终。有时候有些人会返回-10等等一些奇怪的错误，我这里想说 get请求参数是可以验证先后顺序的，注意顺序就好了。
点击预定按钮
/otn/confirmPassenger/initDc & &这个请求主要是获取订单提交时候的2个令牌值(REPEAT_SUBMIT_TOKEN,key_check_isChange)
获取提交订单验证码&
/otn/passcodeNew/getPassCodeNew.do?module=passenger&rand=randp&0.3445
预验证验证码
/otn/passcodeNew/checkRandCodeAnsyn
/otn/confirmPassenger/checkOrderInfo
有人会想问&oldPassengerStr和passengerTicketStr是什么，这里给一段代码把
&&&&&&&&&&&public&static&String&getOldPassengerStr(List&UserInfo&&userInfo)&{&&&&&&&&&&String&oldStrs&=&&&;&&&&&&&&&&for&(int&i&=&0;&i&&&userInfo.size();&i++)&{&&&&&&&&&&&&&&String&oldStr&=&userInfo.get(i).getName()&+&&,&&+&userInfo.get(i).getCardType()&+&&,&&+&userInfo.get(i).getCardID()&+&&,&&+&userInfo.get(i).getType();&&&&&&&&&&&&&&oldStrs&+=&oldStr&+&&_&;&&&&&&&&&&}&&&&&&&&&&return&oldS&&&&&&}&&&&&&&&&&&&&&&&&&&public&static&String&getPassengerTicketStr(List&UserInfo&&userInfo)&{&&&&&&&&&&String&oldStrs&=&&&;&&&&&&&&&&for&(int&i&=&0;&i&&&userInfo.size();&i++)&{&&&&&&&&&&&&&&String&oldStr&=&&&;&&&&&&&&&&&&&&if&(&WZ&&==&userInfo.get(i).getSeatType())&{&&&&&&&&&&&&&&}&else&{&&&&&&&&&&&&&&&&&&oldStr&=&userInfo.get(i).getSeatType();&&&&&&&&&&&&&&}&&&&&&&&&&&&&&String&bR&=&oldStr&+&&,0,&&+&userInfo.get(i).getTickType()&+&&,&&+&userInfo.get(i).getName()&+&&,&&+&userInfo.get(i).getCardType()&+&&,&&+&userInfo.get(i).getCardID()&+&&,&&&&&&&&&&&&&&&&&&&&&&&+&(userInfo.get(i).getPhone()&==&null&?&&&&:&userInfo.get(i).getPhone())&+&&,N&;&&&&&&&&&&&&&&oldStrs&+=&bR&+&&_&;&&&&&&&&&&}&&&&&&&&&&return&oldStrs.substring(0,&oldStrs.length()&-&1);&&&&&&}&&
其实把 &这两个参数怎么拼接的 &可以在js里面找到答案。
获取时时余票
/otn/confirmPassenger/getQueueCount
/otn/confirmPassenger/confirmSingleForQueue
其实 &说到这个应该也就快完了 &剩下的刷票流程短一点，大家可以自己抓包分析。曾经这里出现过无须验证码提交订票信息的漏洞，最近这两天好像修复好了。
其实吧，技术只是一方面，重要的是理解流程。
转载请注明出处：
源码分享：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2535952次
积分：28575
积分：28575
排名：第135名
原创：614篇
转载：89篇
评论：1177条
阅读：51913
(1)(19)(13)(28)(29)(28)(31)(29)(2)(1)(2)(1)(2)(9)(5)(31)(30)(31)(31)(33)(26)(22)(1)(1)(3)(2)(1)(2)(1)(6)(30)(11)(3)(3)(11)(7)(11)(14)(1)(16)(43)(15)(71)(54)下次自动登录
现在的位置:
& 综合 & 正文
CAS 与.net 集成的 “循环重定向”问题分析
近期的一个项目，项目包含了若干的子系统，因为人员配备的原因，项目会包含不同开发语言编写〔java、.net〕的几个子系统。项目从企业应用集成的角度进行架构，除了在应用层面上的“业务流程整合”之外。还有一个就是“身份认证”层面上的集成，身份认证的整合应用了CAS (Central Authentication Service)，它是Yale 大学的 ITS 开发的一套 JAVA 实现的开源的SSO(single sign-on)的服务。
Cas的部署、实现在java项目系统中都很顺利的架设，实现了。但是在.net子系统中遇到了问题，.net下的集成是我今天要说的。
.net集成之初，参考了官上的范例(http://www.jasig.org/cas),它也提供.net客户端的源码下载。但是在调试的时候，出现了“循环请求验证”的现象，Ie的现象是“一直登录”，火狐下直接提示“循环访问”一类的错误。
首先在google直接找解决方法，但是遗憾的是并没有直接解决类似问题的信息。有几篇提到了这个现象，但是并没有提出解决方案，msdn中有这个问题，但是回复者都是三言两语，没有详细的解决方案，有的回答说“官网提供的是个半成品”。无语..暂且信之吧。
问题总是要解决的，以前没有实际使用过这个东西，所以还是从头开始吧，googel了一些cas的知识，对cas的机制，应用过程进行了解。
(具体知识详见 说的很通俗〕。
Cas .net版本的客户端.是结合了asp.net自身的forms认证实现认证的。它是通过编写一个httpModel进行拦截，通过对客户端票据〔ticket〕的检查来实现对每一次请求的过滤，进而达到对功能页面的控制。首先在web.config中要配置一系列的cas服务端的参数信息，直接贴出
&configSections&
&sectionname="casClientConfig"type="DotNetCasClient.Configuration.CasClientConfiguration, DotNetCasClient"/&
&/configSections&
&casClientConfig
casServerLoginUrl="http://192.168.12.196/cas/login"
casServerUrlPrefix="http://192.168.12.196/cas"
serverName="http://localhost:3273/ExampleWebSite"
notAuthorizedUrl="~/NotAuthorized.aspx"
cookiesRequiredUrl="~/CookiesRequired.aspx"
redirectAfterValidation="true"
gateway="false"
renew="false"
singleSignOut="true"
ticketTimeTolerance="5000"
ticketValidatorName="Cas20"
serviceTicketManager="CacheServiceTicketManager"
gatewayStatusCookieName="CasGatewayStatus" /&
&system.web&
.net 自己的Forms认证这的配置也很重要，
&authenticationmode="Forms"&
loginUrl="http://192.168.12.196/cas/login"
timeout="30"
defaultUrl="~/Default.aspx"
cookieless="UseCookies"
slidingExpiration="true"
path="/ExampleWebSite/"
&/authentication&
&authorization&
&denyusers="?"/&
&allowusers="*"/&
&/authorization
最后就是httpModel的配置了
&httpModules&
&addname="DotNetCasClient"type="DotNetCasClient.CasAuthenticationModule,DotNetCasClient"/&
&/httpModules&
至此cas的基础配置完成了，但是这是不够的，这个的配置并没有错，但是实际运行中就会出现上述的“循环验证”的问题，通过分析，发现循环重定向到login页面的原因是每一次的验证都是失败，票据丢失，会话状态丢失。这个是引起循环重定向的直接凶手，
请求系统页面--&httpModel重定向à cas登录页à登录后的系统页面àhttpModel验证ticket失败à重定向登录cas
这个过程周而复始，那么问题的核心在那呢？.“httpModel验证失败”，这个是整个问题过程中的核心，通过调试，最终也确定了导致失败的最终代码段。
CasAuthenticationTicket casTicket = null;
FormsAuthenticationTicket formsAuthenticationTicket = GetFormsAuthenticationTicket();
if (formsAuthenticationTicket != null)
ICasPrincipal
if (ServiceTicketManager != null)
string serviceTicket = formsAuthenticationTicket.UserD
casTicket = ServiceTicketManager.GetTicket(serviceTicket);
if (casTicket != null)
没有发现票据，也就是说票据实失效引起的cas 认证的重定向登录，那么是谁引起的ticket的失效呢？.最终排除了cas客户端和服务端的问题，也就是说cas 配置是正确的，？？那是什么引起最初的“循环重定向”现象呢。“Asp.net forms 验证下的session失效”，问题由cas踢给.net自己的问题。最终问题再次转移了，变成了“在.net下，session失效的问题”，但是也看到了曙光，因为这个问题googel一下.会有太多的信息供你浏览。同时，我发现我被“java 、cas”这样的词误导了。基于.net的cas集成本身并不全是“cas”的问题，.net也是整合的一部分。
直接增加配置：
&sessionStatemode="StateServer"cookieless="UseCookies"timeout="36000"&&/sessionState&
1、启用会话状态，
2、开始asp.net状态服务〔确保会话的持久，不在莫名其妙的失效。〕
3、对一些系统的页面进行页面缓存禁用，因为有几次..缓存的页面又一次误导了，让我以为cas的认证有问题。
通过解决asp.net的会话失效问题，发现应用cas后的“循环重定向”问题没有了。
最后要说一下cas的“登出”操作，“登出”必须要.net forms登出和 cas的服务端登出结合。一定要先将服务端会话Abandon，然后在对cookie进行过期操作。最后清清除cas<span style="font-family: 宋体; mso-ascii-fo
&&&&推荐文章:
【上篇】【下篇】