cas号是什么意思

CAS Registry Number或称CAS Number 又称CAS登录号

这是化学化工方面常常涉及到的一个术语，你查询下相关的网站吧

CAS Registry Number或称CAS Number 又称CAS登录号

是美国化学文摘服务社(Chemical Abstracts Service ,CAS)为化学物质制订的登记号，该号是检索有多个名称的化学物质信息的重要工具。是某种物质（化合物、高分子材料、生物序列（Biological sequences）、混合物或合金的8唯一的数字识别号码。

美国化学会的下设组织CAS负责为每一种出现在文献中的物质分配一个CAS号，其目的是为了避免化学物质有多种名称的麻烦，使数据库的检索更为方便。如今几乎所有的化学数据库都允许用CAS号检索。到2005年12月25日，CAS已经登记了27,115,156种物质最新数据 ，并且还以每天4,000余种的速度增加。

格式 :一个CAS号以连字符“-”分为三部分，第一部分有2到6位数字，第二部分有2 位数字，第三部分有1位数字作为校验码。CAS号以升序排列且没有任何内在含义。校验码的计算方法如下：CAS顺序号（第一、二部分数字）的最后一位乘以1，最后第二位乘以2，依此类推，然后再把所有的乘积相加，再把和除以10，其余数就是第三部分的校验码。举例来说，水（H2O）的CAS号前两部分是7732-18，则其校验码＝（8×1＋1×2＋2×3＋3×4＋7×5＋7×6）mod 10＝105 mod 10＝5。（mod是求余运算符）

异构体、酶和混合物: 不同的同分异构体分子有不同的CAS号，比如右旋葡萄糖（D-glucos）的CAS号是50-99-7，左旋葡萄糖（L-glucose）是921-60-8，α右旋葡萄糖（α-D-glucose）是26655-34-5。 偶然也有一类分子用一个CAS号，比如一组乙醇脱氢酶（Alcohol dehydrogenase）的CAS号都是9031-72-5。混合物如芥末油（mustard oil）的CAS号是8007-40-7。

官方网站：http://www.cas.org/

1.查询CAS登记号，中文名、英文名及其别名，分子量、分子式，熔点、沸点，部分有性质介绍。

2.可以输入中文名称、英文名称、CAS编号或者分子式进行查询。

3.部分记录有多个中文名称和多个英文名称。

4.关键词、字的前后顺序会影响检索结果，例如在中文名称中检索“胺 乙基”和“乙基 胺”，检索结果会不同： 检索“胺 乙基”时，会检索到二乙胺基乙基纤维素，但不会检索出四乙基乙二胺。 检索“乙基 胺”时，会检索到四乙基乙二胺，但不会检索出二乙胺基乙基纤维素。

5.使用CAS编号查询时需输入完整的CAS编号，包括"-"，如“100-00-5”。

【拓展资料】

一、CAS号是什么？

1.cas编号的中文全称为“化学物质登录号”，由一组数字组成。就像我们都有自己唯一的身份证一样，每一种已经发现的化合物都有自己唯一对应的编号。 2.这种编号的出现，可以弥补化学物质命名不统一而引起的种种麻烦。比如对于同一物质，各个国家的命名方法不同，有很多物质既有化学名称，又有俗名。 3.这样一来，经常发生数据不全的现象。而cas编号唯一对应一种物质，很容易解决这个问题。只要知道这个物质的cas编号，就可以很快，很轻松地查询最全面的资料。 4.下面简单说一下cas编码的组成。由六位到九位的数字组成。其一般形式为【####aa-aa-a】。其中#表示可有可无的数字，a表示必须有的数字。也就是说最前面的数字位数是不一定的，有些物质是两位，最多可达六位。然而无论是什么化合物，必需至少有五位数组成。在原则上，数字大小可以反映物质发现的早晚，数字越大，表示发现得越晚。现在已有2000万余种物质有自己的cas编号。 5.cas编号最早出现于美国化学摘要服务社（chemical abstracts service，CAS即为该服务社的缩写)出版的《化学摘要》，与其同时研发的网上检索系统，后来凭借无比的优越性，其他出版社也采用cas编码来标明化学物质，现在海关化学物品进出口，也要登录该资料。

的原理是分布式会话来实现。

比如说现在有个一级域名为 www.p2pi.cn ，是IT类网站，但是网站又可细分为不同的领域，可以通过构建二级域名提供服务给用户访问，比如： blog.p2pi.cn 、 wallpaper.p2pi.cn 、 download.p2pi.cn 等等，分别为博客、壁纸、资源网站等，只要用户在其中一个站点登录，那么其他站点不用重新登录。

也就是说，用户自始至终只在某一个网站下登录后，那么他所产生的会话，就共享给了其他的网站，实现了单点网站登录后，同时间接登录了其他的网站，那么其实这个就是单点登录，他们的会话是共享的，都是同一个用户会话。

分布式会话后端的实现可以是基于redis的，如此会话可以流窜在后端的任意系统，都能获取到缓存中的用户数据信息，前端通过使用cookie，可以保证在同域名的一级二级下获取，那么这样一来，cookie中的信息是可以在发送请求的时候携带上的，这样从前端请求后端后是可以获取拿到的，这样一来，其实用户在某一端登录注册以后，其实cookie和redis中都会带有用户信息，只要用户不退出，那么就能在任意一个站点实现登录了。

前端代理里面需要设置

SwitchHosts 需要配置host信息

通过访问测试，发现在用户登录之后，两个站点是能够共享用户信息的。

只要前端网页都在同一个顶级域名下，就能实现cookie与session的共享，具体流程如下：

当用户访问 www.p2pi.cn 网站登录之后，会生成cookie存在，接着去访问 www.p3p.cn ，这个时候由于顶级域名不同，cookie是无法携带过去的，需要你进行二次登录，如下图所示：

这个时候就需要用其他方式，实现顶级域名不同的时候，实现单点登录，这里可以使用CAS，具体流程如下：

如上图所示，多个系统之间的登录会通过一个独立的登录系统去做验证，所有系统的登录都需要经过这个系统，实现了统一登录。这个就称之为CAS系统。

CAS全称为 Central Authentication Service 即中央认证服务，是一个单点登录的解决方案，可以用于不同顶级域名之间的单点登录。

在分布式系统架构中，假设把上述的三个子系统部署在三个不同的服务器上。前提是用户登录之后才能访问这些子系统。那么使用传统方式，可能会存在这样的问题：

1.当访问用户中心，需要用户登录帐号

2.当访问购物车，还需要用户登录帐号

3.当访问商品结算，又一次需要用户登录帐号

访问每一个子系统都需要用户登录帐号，这样的体验对于用户来说是极差。而使用单点登录就可以很好地解决上述的问题。

二，单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

我们目前的系统存在诸多子系统，而这些子系统是分别部署在不同的服务器中，那么使用传统方式的 session 是无法解决的，我们需要使用相关的单点登录技术来解决。

第一步 ：用户访问应用系统1。过滤器判断用户是否登录，没有登录，则重定向（302）到认证系统去进行认证操作。

第二步 ：重定向到认证系统，显示登录界面，用户输入用户名密码。认证系统将用户登录的信息记录到服务器的session中。

第三步 ：认证系统给浏览器发送一个特殊的凭证ticket，浏览器将凭证交给应用系统1，应用系统1则拿着浏览器交给他的凭证ticket去认证系统验证凭证ticket是否有效。凭证ticket若是有效，将用户信息保存到应用系统1的session中一份，并告知应用系统1，用户通过认证。

第四步 ：用户通过认证，浏览器与网站之间进行正常的访问。

第五步 ：当用户再次访问应用系统1，由于应用系统1的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问应用系统1了。

第六步 ：当用户再去访问其他应用系统时，浏览器会带着凭证ticket过去，其他应用系统到认证系统验证凭证，凭证ticket若是有效，将用户信息保存到其他应用系统的session中一份，并告知其他应用系统，用户通过认证。

第七步 ：用户通过认证，浏览器与网站之间进行正常的访问。

第八步 ：当用户再次访问其他应用系统，由于其他应用系统的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问其他应用系统了。

三、Yelu大学研发的CAS(Central Authentication Server)

1.什么是CAS？

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：

【1】开源的企业级单点登录解决方案。

【2】CAS Server 为需要独立部署的 Web 应用。这个CAS框架已经提供

【3】CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。下图是 CAS 最基本的协议过程：

2.CAS的详细登录流程

该图主要描述

1.第一次访问http://shopping.xiaogui.com

2.在登录状态下第二次访问http://shopping.xiaogui.com

3.在登录状态下第一次访问http://pay.xiaogui.com

下面对图中序号代表的操作进行说明

当用户第一次访问http://shopping.xiaogui.com

序号1: 用户请求http://shopping.xiaogui.com，会经过AuthenticationFilter认证过滤器(在cas client 的web.xml中配置)

主要作用：判断是否登录，如果没有登录则重定向到认证中心。

大概知道这个就行，CAS的具体实现会在以后的博客中写道

序号2:  AuthenticationFilter发现用户没有登录，则返回浏览器重定向地址。

重定向的地址就是认证服务器CAS Server的地址，后面的参数是我们请求的客户端地址，这个参数目的就是为了认证成功以后，根据这个参数的地址重定向回请求的客户端

序号3:  浏览器根据响应回来的重定向地址，向cas.xiaogui.com认证系统发出请求

序号4:  认证系统cas.xiaogui.com接收请求，响应登陆页面

序号5: ：用户登陆页面输入用户名密码，提交请求

序号6: ：CAS Server 认证服务器接收用户名和密码，就行验证，验证逻辑CAS Server 已经实现，并响应给浏览器信息

这里的用户名，密码不需要关心，后续会讲到

图中1，2部分表示序号5 输入的用户名，密码，以及发出的请求。当认证服务器验证通过之后，根据请求参数service的值，进行重定向，其实就是回到了请求的客户端，同时会携带一个ticket令牌参数。同时会在Cookie中设置一个TGC，该cookie是网站认证系统cas.xiaogui.com的cookie，只有访问这个网站才会携带这个cookie过去。

*****注意：这个携带TGC的Cookie是实现CAS单点登录的关键所在！

Cookie中的TGC：向cookie中添加该值的目的是当下次访问cas.xiaogui.com认证系统时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。

TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）

TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。

ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值。

序号7:  客户端拿到请求中的ticket信息，也就是图中1的位置

然后经过一个ticket过滤器Cas20ProxyReceivingTicketValidationFilter，去认证系统CAS Server判断ticket是否有效

这个过滤器的主要工作就是校验客户端传过来的ticket是否有效

CAS Client 客户端  shopping.xiaogui.com  中web.xml的配置

序号8:  向CAS Server认证系统发出验证ticket的请求，也就是图中2的位置，然后执行ticket验证

序号9:  通过校验之后，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中，同时告知客户端ticket有效。当用户再次访问该客户端，就可以根据Cookie 中的SessionID找到客户端的Session，获取用户信息，就不用再次进行验证了。也就是图中响应给浏览器的部分。

序号10:  shopping.xiaogui.com客户端接收到cas-server的返回，知道了用户已经登录，ticket有效，告知浏览器可以进行访问。

至此，用户第一次访问流程结束。

当用户第二次访问http://shopping.xiaogui.com

序号11: 当用户第二次访问，仍然会经过AuthenticationFilter过滤器，但与第一次访问不同的是此时客户端session中已经存在用户的信息，浏览器中的Cookie会根据SessionID找到Session，获取用户信息，所以不需要进行验证，可以直接访问。

序号12:  客户端告知浏览器可以进行访问。

当用户第一次访问http://pay.xiaogui.com

序号13:   用户向pay.xiaogui.com  CAS Client客户端发出请求

序号14:  ：pay.xiaogui.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录。

序号15: 浏览器根据上面响应的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。

序号16:  认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ticket，并且返回给浏览器，让他重定向到pay.xiaogui.comCAS Client客户端。

序号17: 根据上面响应回来的地址，进行重定向到pay.xiaogui.comCAS Client客户端

序号18:  pay.xiaogui.comCAS Client客户端带着ticket去认证中心验证是否有效。

序号19:  认证成功，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中。当用户下次访问pay.xiaogui.comCAS Client客户端，直接登录，无需验证。

序号20:  告知浏览器可以进行访问

CAS单点登录的原理分析大致就是上述的这些，至于CAS单点登录的具体实现，将在下篇博客中写道。

TGT（Ticket Grant Ticket）：是cas服务端为用户签发的登录票据，封装了cookie和用户信息，有TGT代表用户已经登录过。

TGC(Ticket Granting Cookie)：可以理解成TGT的cookie，cookie的值就是TGT的ID。

ST(service Ticket)：cas服务端签发的访问某个服务的票据，server用TGT去签发ST

二、基本原理

现有webClient1、webClient2访问CASServer，分析流程：

1、首先：请求webClient1

1）、请求webClient1的request被CASAuthencationFilter拦截，将该请求的url作为sevice参数，重定向至cas/login；

2）、CAS检测到请求中没有TGC，跳转至自己的登录界面；

3）、登录验证通过，CASServer生成TGT和ST，并将TGT的id写到浏览器（TGC），将ST做为参数，重定向至webClient1。

4）、此时webClient1的CASAthencationFilter会通过，此时被TicketVaildationFilter拦截，这个过滤器发送httpClient请求去验证ST的正确性，server验证通过，将用户信息写到wenClient1的session中。

现在SSO会话就建立起来了。

2、然后，再次访问webClient1，会直接去自己的session中拿取用户信息，不需要服务端验证。

3、浏览器未关闭情况下访问webClient2

1）、webClient2检测自己的session中没有用户信息，request被CASAuthencationFilter拦截，将该请求的url作为sevice参数，重定向至cas/login；

2）、此时请求中会有TGC，CASServer会根据TGC查找到TGT，然后用TGT去签发ST

接下来就是1.4中的步骤了。