&&&&&&&&&&&&
您的位置：&&& &&&&& &&&&& &&正文
足协连开6罚单:青岛赛区被警告 国安小将停四场
&&&&昨天，足协公布6条处罚通知，国安球员李提香在比赛中辱骂裁判员，被足协禁赛4场，罚款2万元。此外,青岛赛区也被足协处罚。
&&&&1989年出生的李提香近些年职业之路发展并不顺利，他在2011年首次代表国安在正式比赛中登场，此后多数时间在预备队中度过；今年年初以租借方式加盟葡甲球队，回归国安后也一直未能获得联赛出场机会，仍在预备队锻炼。在7月31日的预备队联赛中，李提香在比赛中指责辱骂裁判员，遭到足协的严厉处罚。
&&&&此外，上轮中甲联赛，广东队主帅麦超被青岛球迷从看台扔下的矿泉水瓶砸晕，足协决定对青岛赛区书面警告、罚款3万元。同时，在卓尔与北理工比赛中，王超和朱挺互相暴力攻击，均被停赛3场、罚款1.5万元。
[ 责任编辑：体育小编 ]
原稿件标题：
原稿件标题URL：
原稿件作者：
转载编辑：体育小编
原稿件来源：CAS协议 - CAS URIs - 如果你真的想做一件事，你一定会找到方法； 如果你不想做一件事，你一定会找到借口。 - ITeye技术网站
博客分类：
2.CAS URIs:
CAS是一个基于HTTP的协议，这就要求其每一个组成部分可以通过特定的URIs访问到。所有相关的URIs如下：
2.1. /login as credential requestor
2.2. /login as credential acceptor
2.3. /logout
2.4. /validate [CAS 1.0]
2.5. /serviceValidate [CAS 2.0]
2.6. /proxyValidate [CAS 2.0]
2.7. /proxy [CAS 2.0]
2.1. /login as credential requestor
/login URI通过两种行为运转：一是作为一个凭证索取者，二是作为凭证接收者。根据它对凭证的反应来区分他是作为凭证索取者还是凭证接收者。
如果客户端已经与CAS建立了一个单点登录的session，Web浏览器给CAS一个安全的cookie，里面包含有一个以字符串形式存在的身份信息—TGT（Ticket-Granting Ticket），存储这个身份信息TGT的cookie就被称为票证授予的cookie（TGC- Ticket-Granting Cookie）。如果TGC里面有一个有效的TGT，CAS可以发出一个服务门票（Service Ticket，ST），这个ST可以在本规范内的其他任何情况下使用。本规范的要求。见第3.6节提供更多的资料，TGC。
2.1.1. parameters
当/login作为凭证索取者时，包含下面的HTTP请求参数。它们都是区分大小写的，他们都必须能被/login处理。
service[可选] -客户端尝试访问的应用的标识符。在几乎所有情况下，这将是应用的URL。请注意，作为一个HTTP请求的参数，此URL的值必须是符合RFC 中URL编码的描述。（详情参见 [ 4 ]的第2.2节）。
如果没有指定service并且单点登录session尚不存在，CAS应要求具有凭证的用户发起一个单点登录session。
如果没有指定service但单点登录session已经存在，CAS应显示一条消息，通知客户，这是已经登录
renew[可选] -如果此参数设置，单点登录将被绕过。在这种情况下，CAS将要求客户提交证书，不论是否存在一个CAS的单点登录session。这个参数与“gateway”参数不兼容。服务重定向到/login URI（get方式访问/login）和提交到/login URI的登录表单视图（post方式访问/login）中不应同时出现“renew”和“gateway”请求参数。
注：即两个参数都设置这种行为是未定义的。CAS推荐：在实施时，如果设置了“renew”参数则忽略“gateway”参数。推荐：当设置“renew”参数时，其值应该为“true”。
注：也就是说：https://server/cas/login?service=serviceUrl&renew=true&gateway=true这种参数传递是错误的，不能同时出现两个参数。
注：CAS协议允许客户端选择是否跳出单点登录（强制重新登录），这就是renew。它允许一个客户端通知CAS服务器总是验证一个用户，不管一个单点登录的session是否存在。这是一个非常有用的属性，当一个特定的使用CAS认证机制的服务允许访问敏感资料时，它能强迫CAS重新认证一个用户，确保登录的是一个正确的用户。这时，那个应经存在的单点登录session应该是被终止的。使用这个属性通知CAS重新验证凭证时，客户端应用应该重定向用户到以下的URL上：https://server/cas/login?service=serviceUrl&renew=true。当请求验证这个票据时，客户端可以要求CAS确保这个票据是来自一个新的认证请求。
gateway[可选] -如果这个参数设定，CAS将不会向客户端索要凭据。
如果客户端有一个已存在的CAS单点登录的session，或者如果单点登录session可以通过非交互方式（i.e. trust authentication，信托认证）建立，CAS可以将客户端请求重定向到“service”参数指定的URL，而且还加上有效的服务票据（Service Ticket，ST）。 （CAS还可以插入一个通知页面，通知客户端一个CAS认证已经发生了。）
如果客户端没有CAS单点登录的session，并且也不可能通过非交互方式建立认证，CAS必须将客户端重定向到“service”参数指定的URL，并且不在URL后面附加“ticket”。
如果“service”参数未指定但设置了“gateway”参数，CAS将认为这种行为未定义。在这种情况下推荐：CAS应要求客户端凭据就好像两个参数都没有指定。
同样这个参数与“renew”参数不兼容。如果要设置“gateway”参数，推荐设置为“true”。
总结：“renew”参数的作用：在存在SSO session的情况下，当client请求访问资源，renew参数控制CAS认证服务器重新认证用户信息、还是不用认证放这个请求过去。
总结：“gateway”参数的作用：与“renew”参数相反，“gateway=true”时是指只要存在SSO session就不用重新认证了。
总结：Renew始终要求用户进行主认证，所谓主认证就是借助于/login进行的认证操作，此时IE用户必须手工提供自身的帐号信息。基于TGC、PT的登录都不属于主认证。
相比之下，gateway始终不会允许CAS服务器丢出/login登录页面给IE用户，从而不可能进行主认证。只要gateway=true则永远进不到/login登录页面，只有确认用户能从其他途径得到SSO session才可以设置true。
2.1.2. URL examples of /login
Simple login example: https://server/cas/login?service=http%3A%2F%
Don't prompt for username/password: https://server/cas/login?service=http%3A%2F%&gateway=true
Always prompt for username/password: https://server/cas/login?service=http%3A%2F%&renew=true
2.1.3. response for username/password authentication
当/login的行为作为凭证索取者时，根据请求的证书的类型响应会有所不同。
在大多数情况下，CAS作出的回应是显示登录屏幕要求输入用户名和密码。此网页必须是包括“用户名”，“密码”，“lt：login ticket”参数的表单。该表单也可包括 “warn”参数 。如果“service”已被指定为从/login登录，那么“service”也成了登录表单的一个参数，包含着通过/login以后最初的地址。将在第2.2.1节对这些参数进行详细的讨论。该表单必须通过HTTP POST方法来提交到/login，然后/login就作为凭据接收人，将在第2.2节讨论。
2.1.4. response for trust authentication
信任认证作为一种基本的认证，对各种各样的请求都考虑了进去。信任认证的用户体验就是高度详尽的部署，考虑本地策略和特殊情况下认证机制的实现。
当/login行为作为信任认证的票据索取者时，其行为将取决于接收的证书的类型。如果证书是有效的，CAS会立即将用户重定向到请求的服务。另外，CAS可能会显示一个警告信息：证书是存在的，并允许客户端确认它是否想利用这些证书。推荐：CAS的实施允许部署者选择首选行为。如果证书是无效的或不存在，CAS推荐显示客户端验证失败的原因，以及可能替代目前的用户身份验证的其他方式（如用户名/密码身份验证）。
2.1.5. response for single sign-on authentication
如果客户已经建立了一个CAS的单点登录session，客户端将带着自己的HTTP会话cookie来/login ，并予以处理的行为将在第2.2.4节。但是，如果“renew”参数设置了，处理行为参见第2.1.3或2.1.4 。
2.2. /login as credential acceptor
当一组接收的证书（客户端认证：用户名、密码或者信任认证）通过了/login，/login将扮演凭证接收者的角色，具体行为将在本节定义。
2.2.1. parameters common to all types of authentication
当/login作为凭据接收人时，下面的HTTP请求参数可能被传递到/login。他们都是区分大小写的，它们都必须能被/login处理。
service[可选] -客户端尝试访问的应用的URL。成功验证后CAS必须将客户端重定向到这个URL。这是详细讨论了第2.2.4节。
warn[可选] -如果此参数设置，单点登录将不能是透明。客户端必须被提示通过了验证正在转向请求的服务。
2.2.2. parameters for username/password authentication
除了在第2.2.1节指明的可选参数，当/login作为用户名/密码认证方式的接收人时，下列HTTP请求参数必须被传递到/login。他们都区分大小写。
username[需要] -正在试图登录的客户端的用户名。
password[需要] -正在试图登录的客户端的用户密码。
lt[需要] -a login ticket登入票证。为什么需要Login ticket参考：。登录门票将在第3.5节讨论。
2.2.3. parameters for trust authentication
Trust authentication没有其他额外的HTTP参数。它可能基于HTTP请求的任何方面。
2.2.4. response
/login作为凭证接收者时，必须返回下面其中一个响应。
成功登入：在不将客户端凭证传递给service的情况下，重定向客户端请求到“service”参数指定的网址。这种重定向的结果必须导致客户端向它所请求的服务发出一个GET请求。要求必须包括一个有效的服务票据（Service Ticket，ST），作为HTTP请求的参数通过，它就是“ticket” 。见附录B获取更多信息。如果“服务”未指定，CAS必须通知客户端，它已成功地开始了一个单点登录session。
登入失败：以凭证索取者的身份重新迁移到/login。因此建议在这种情况下，CAS服务器向用户显示错误信息，说明为什么登入失败（例如密码错误，锁定帐户等） ，如果有必要的话，提供一个机会，让用户能够尝试再次登录。
2.3. /logout
/logout用于销毁客户端的CAS单点登录会话。TGC被摧毁（第3.6节），随后请求/login将不会取得服务门票（ST），直到用户再次交出主凭证（从而建立了一个新的单点登录session）。
2.3.1. parameters
以下是/logout的HTTP请求参数。这是区分大小写的，应由/logout来处理。
url[可选] -如果“url”被指定的，那么在登出页面上需要有一个link到url并带有描述性文字的链接。例如，登出页面上：“您刚登出的财务系统提供了一个链接，如果你想访问，请单击此处（此处代表一个link到http://www.go-back.edu的超级链接）.”
2.3.2. response
/logout必须展示一个页面，向用户表明现在已经登出。如果“url”请求参数被指定，登出页面还应提供一个链接到url的链接，具体描述在第2.3.1 。
2.4. /validate [CAS 1.0]
/validate检查ST的有效性，/validate是CAS1.0协议的一部分，因此它不能处理代理认证。当一个代理凭证被传递给/validate时，CAS必须发出一个服务凭证验证失败的响应。
2.4.1. parameters
下面的HTTP请求参数可以被传递给/validate。它们是区分大小写的，必须全部能被/validate处理。
service[需要] –服务的标识符，是需要带着ticket访问的服务。
ticket[需要] -/login发出的服务凭证（ST）。服务凭证的描述见3.1节。
renew[可选] -如果这个参数设定，凭证验证将只在ST是来自用户的主证书时才会通过验证，如果ticket是来自SSO session，则验证失败。即，只有通过主登录页面过来的附带着ST的请求，才能被验证。
2.4.2. response
/validate 将返回下面的2个响应之一。
ticket验证成功：
username&LF&
ticket验证失败：
2.4.3. URL examples of /validate
Simple validation attempt: https://server/cas/validate?service=http%3A%2F%&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7
Ensure service ticket was issued by presentation of primary credentials: https://server/cas/validate?service=http%3A%2F%&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true
2.5. /serviceValidate [CAS 2.0]
/serviceValidate检查ST的有效性，并且返回一个XML片段。 当被请求时，/serviceValidate还必须创造和传出PGT（proxy-granting ticket，代理准许凭证）。如果/serviceValidate收到一个PT（proxy ticket，代理凭证），它不能返回一个成功的验证响应。CAS推荐：如果/serviceValidate收到PT，应该在返回的XML响应的错误信息里说明失败的原因，原因是由于PT传递到了/serviceValidate。也即：/serviceValidate不能用来验证PT。
2.5.1. parameters
下面的HTTP请求参数可以被传递给/serviceValidate。它们是区分大小写的，必须全部能被/serviceValidate处理。
service[需要] -服务的标识符，是需要带着ticket访问的服务。第2.2.1节。
ticket[需要] - /login发出的服务凭证（ST）。ST将在3.1节详解。
pgtUrl [可选] -代理回调的URL，CAS通过该回调接口给申请作为代理的服务传递pgt和pgtIou。将在2.5.4节讨论。
renew[可选] -如果这个参数设定，凭证验证将只有在ST是来自用户的主认证时才会通过验证，如果ticket是来自SSO session，则验证失败。
2.5.2. response
/serviceValidate将返回一个格式化的CASserviceResponse XML，详细描述参加附录A。
凭证验证成功：
&cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'&
&cas:authenticationSuccess&
&cas:user&username&/cas:user&
&cas:proxyGrantingTicket&PGTIOU-d...
&/cas:proxyGrantingTicket&
&/cas:authenticationSuccess&
&/cas:serviceResponse&
凭证验证失败：
&cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'&
&cas:authenticationFailure code="INVALID_TICKET"&
Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized
&/cas:authenticationFailure&
&/cas:serviceResponse&
2.5.3. error codes
下面的值可能被用来作为验证失败时“code”属性的值。以下是最低限度的错误代码，所有CAS服务器都必须实现的，当然还可以包括一些其他实现。
INVALID_REQUEST -请求参数不全。上面讲到至少必须有“service”和“ticket”两个参数。
INVALID_TICKET -提供的ticket无效，或者你的“renew”属性设置为true，而不是从主认证（/login）过来的。返回的XML中的消息体中的&cas:authenticationFailure&块应说明具体细节。
INVALID_SERVICE -提供ticket是有效的，但是和ticket关联的service并不匹配。此时：CAS必须使这张ticket失效，并禁止今后再验证该ticket。
INTERNAL_ERROR –在ticket验证时发生内部错误。
对于所有的错误代码，CAS推荐在&cas:authenticationFailure&的内容区域提供更详细的错误原因描述。
2.5.4. proxy callback
如果一个服务想代理一个客户端到终端服务（Back-end service）的认证，他必须获得一个PGT（proxy-granting ticket，代理授予凭证）。通过传递参数pgtUrl（代理回调URL）来控制CAS在验证时是否同时返回PGT。这个URL将唯一的和安全的识别终端服务，并且代理客户端的认证请求。终端服务然后基于自身的识别回调URL来决定是否接受这个证书。
代理回调机制的工作流程如下：
1.当ST或者PT通过/serviceValidate（或/ proxyValidate）进行验证时，如果设置了参数“pgturl”，service才会向CAS认证服务器请求产生PGT(proxy-granting ticket)。pgturl是一个服务的回调URL，CAS服务器将用pgturl来验证服务的身份信息。这个URL必须是HTTPS的，并且CAS必须确认SSL证书是有效的，并且它的名字与它请求的服务相匹配。如果证书验证失败，将不发放PGT，并且就像第2.5.2节中描述的，必须使CAS服务返回的XML中不包含&proxyGrantingTicket&这个xml块。此时，将停止发布PGT，但ST验证仍将继续，还要根据具体情况返回成功或失败状态。如果证书验证成功，发行PGT的过程见如下第2步。
2.CAS将使用HTTPS GET方式传递参数“pgt”和“pgtIou”给pgtUrl。这些实体将在第3.3和3.4中讨论。即通过访问代理服务器上的https回调接口，传递pgt和pgtIou给代理服务器
3.如果HTTP GET返回的HTTP状态码是200 （正常），CAS必须在/serviceValidate （或/proxyValidate ）的请求（第2.5.2节）响应结果中包含有PGTIOU（Proxy-granting ticket IOU）（第3.4节）的&cas:proxyGrantingTicket&节点。
如果HTTP GET返回的是其他状态码（除了HTTP 3xx重定向外），CAS必须在/serviceValidate （或/proxyValidate ）的请求（第2.5.2节）响应结果中不包含PGTIOU（Proxy-granting ticket IOU）和&cas:proxyGrantingTicket&节点。CAS可跟踪pgturl发出的任何HTTP重定向连接。但不管怎样，在&proxy&节点中提供验证的回调URL，必须与最初通过/serviceValidate （或/proxyValidate ）的“pgturl”参数相同。
4.service会从CAS响应中收到一个PGTIOU，同时会从proxy callback中收到一个PTG和PGTIOU。然后service会使用PGTIOU与PGT进行匹配（CAS响应的PGTIOU和回调url返回的PGTIOU一致的话，回调接口返回的pgt才正式生效）。这样就能找到需要的PGT，利用这个PGT就可以得到PT（proxy-ticket）。参见第2.7节。
2.5.5. URL examples of /serviceValidate
Simple validation attempt: https://server/cas/serviceValidate?service=http%3A%2F%&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7
Ensure service ticket was issued by presentation of primary credentials: https://server/cas/serviceValidate?service=http%3A%2F%&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true
Pass in a callback URL for proxying: https://server/cas/serviceValidate?service=http%3A%2F%&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&pgtUrl=https://my-server/myProxyCallback
2.6. /proxyValidate [CAS 2.0]
/proxyValidate必须执行与/serviceValidate相同的验证任务，并且额外地还要能验证PT。/proxyValidate必须能够验证ST和PT。
2.6.1. parameters
/proxyValidate与/serviceValidate所使用的参数完全相同，请参见2.5.1。
2.6.2. response
/proxyValidate能够返回一个格式化的CAS服务响应XML，此XML的结构参见附录一。
ticket验证成功：
&cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'&
&cas:authenticationSuccess&
&cas:user&username&/cas:user&
&cas:proxyGrantingTicket&
PGTIOU-d...
&/cas:proxyGrantingTicket&
&cas:proxies&
&cas:proxy&https://proxy2/pgtUrl&/cas:proxy&
&cas:proxy&https://proxy1/pgtUrl&/cas:proxy&
&/cas:proxies&
&/cas:authenticationSuccess&
&/cas:serviceResponse&
请注意，当认证已开始通过多重代理进行时，一组代理的顺序要反映在&cas:proxies&块中。最近访问代理必须首先出现在代理链上，然后按照代理的新旧顺序依次添加到代理链上。在上面的例子中，服务确定的第一个访问代理的网址是：https：//proxy1/pgtUrl，并且服务的代理认证是依靠第二个URL-https：//proxy2/pgtUrl辨别出来的。
注：代理链&cas:proxies&里面放的是一组代理，是指获取PT的路径。它的顺序代表着同被代理者的远近关系，同被代理者更近的代理者出现在更前面。
ticket验证失败：
&cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'&
&cas:authenticationFailure code="INVALID_TICKET"&
ticket PT-HMgO86Z2ZKeByc5XdYD not recognized
&/cas:authenticationFailure&
&/cas:serviceResponse&
2.6.3 URL examples of /proxyValidate
/proxyValidate与/serviceValidate一样接受相同的参数。参阅第2.5.5使用范例。
2.7. /proxy [CAS 2.0]
/proxy为已经获取PGT的服务提供PT，并且可以为后端服务做代理认证。
2.7.1. parameters
下面的HTTP请求的参数是/proxy必须指定的。他们都区分大小写。
pgt [需要] –代理服务在验证ST和PT后所获取的PGT。
targetService [需要] -后端服务的标识符。请注意，并非所有的后端服务都是web服务，因此这一标识符不会永远是URL。但是不管怎样，这里指定的服务标识符必须匹配/proxyValidate验证时的“service”参数。
2.7.2. response
/proxy能够返回一个格式化的CAS服务响应XML，此XML的结构参见附录一。
PT申请成功：
&cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'&
&cas:proxySuccess&
&cas:proxyTicket&
PT-xZrQN4p90ASrw96c8
&/cas:proxyTicket&
&/cas:proxySuccess&
&/cas:serviceResponse&
PT申请失败：
&cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'&
&cas:proxyFailure code="INVALID_REQUEST"&
'pgt' and 'targetService' parameters are both required
&/cas:proxyFailure&
&/cas:serviceResponse&
2.7.3. error codes
下面的值可能被用来作为验证失败时“code”属性的值。以下是最低限度的错误代码，所有CAS服务器必须实现的，当然还可以包括一些其他实现。
INVALID_REQUEST -请求参数不全。上面讲到至少必须有“service”和“ticket”两个参数。
BAD_PGT -提供的PGT无效。
INTERNAL_ERROR –在ticket验证时发生内部错误。
对于所有的错误代码，CAS推荐在&cas:authenticationFailure&节点的内容区域提供更详细的错误原因描述。
2.7.4. URL example of /proxy
Simple proxy request: https://server/cas/proxy?targetService=http%3A%2F%&pgt=PGT-Y9Sa2vTM7hda7xNTkezTbVge4CUsybAr...
(264.2 KB)
下载次数: 94
浏览: 664543 次
来自: 合肥
路径必须是英文,无空格.否则启动cda.bat 出错. 1.1 ...
给你一个验证工具：http://www.atool.org/c ...
谢谢，学习了
我也遇到同样的问题javax.mail.MessagingEx ...
qq 写道刚开始尝试play，感觉不错，但是 ...消除IE的黄色警告的方法，以及save from url的使用 -
- ITeye技术网站
博客分类：
“为帮助保护您的安全，Internet Explorer 已经限制此文件显示可能访问您计算机的活动内容。单击此处查看选项…”
计算机上的网页尝试运行脚本或 ActiveX 控件时，该消息出现。Internet Explorer 将阻止该活动，这样您可以查看没有脚本或 ActiveX 控件时网页的工作方式；通常，您可以在不使用活动内容因而没有安全风险的情况下查看或使用网页。因为脚本或 ActiveX 控件可能对您的计算机有害，所以您应该在决定授予 ActiveX 控件访问您计算机的权限前确定您信任该脚本或 ActiveX 控件的发行商。
如果您确定需要允许网页在您的本地计算机上运行脚本和 ActiveX 控件，请按照下列步骤进行操作：
1.单击“信息栏”。
2.单击“允许被阻止的内容”。
有关如何决定是否应该信任网站或发行商的信息，请单击“相关主题”。
解决方法：
注意：您可以向本地 HTML 文件中添加一条“saved from URL”注释，以指示 Internet Explorer 对本地计算机上的 HTML 内容应用其他区域的设置。例如，您可以向一个本地 HTML 文件中添加一条“saved from URL”注释，以便可以将该 HTML 文件分配到 Internet 区域而不是本地计算机区域。如果您在 Internet 区域中允许脚本、签名的 ActiveX 控件和 Java 小程序，那么该本地 HTML 文件将使用这些缩减的安全权限运行。要指示 Internet Explorer 对名为 Test.htm 的本地 HTML 文件使用 Internet 区域，请向 Test.htm 中添加以下注释。请在 &HTML& 标记前面单独使用一行来添加该注释。
&!-- saved from url=(0023)/ --&
其中，(0023) 值是它后面的 URL 的字符串长度，Contoso 是 Internet Web 站点的名称。当 Internet Explorer 打开 Test.htm 时，Internet Explorer 将查找“saved from URL”注释，并使用适合该 URL 的区域设置来确定对该 Web 页应用哪种安全策略。
但是上面的做法会导致页面上的链接不可用
于是又改成了下面的写法：
&!-- saved from url=(0014)about:internet --&
浏览: 7489 次
来自: 无锡}