目前多数邮局服务提供商，就安全性保障来讲，仅仅局限于https登录，对于登录成功之后，用户的所有请求，均采用普通的http模式。三五邮局从 用户的安全性考虑，对邮局产品进行了重大升级，提供用户从登录服务开始，直至访问服务结束，全程采用ssl保护模式功能
目前多数邮局服务提供商，就安全性保障来讲，仅仅局限于https登录，对于登录成功之后，用户的所有请求，均采用普通的http模式。三五邮局从 用户的安全性考虑，对邮局产品进行了重大升级，提供用户从登录服务开始，直至访问服务结束，全程采用ssl保护模式功能。下面一起分享下关于三五邮局产品 全程ssl保护解决方案。
??一、众所周知，要实现全程https访问，首先就要解决ssl证书的问题。对于普通的应用服务来说，一个域名对应于一个服务，那么购 买、配置ssl证书完成https全程访问，并不是一件复杂的事情。而对于像我司这种专注于saas服务的公司来说，大多数客户都是通过自己的域名来登录 自己购买的服务的。所以多个域名就必须共享一个ssl证书（一个域名用户购买一个证书不可行）。所以按照类似多域名单ssl证书登录的模式，我们采用 https全程通过统一地址进行访问。
例如：mail.a.com访问webmail，mail.b.com访问webmail，则两个域名登录之后统一采用https://mail.serverhost.com进行访问。
二、我们的所有的产品线基于cas的单点登录。所以在实现邮局产品的全程https访问时，就主要需要对jasig?cas?进行一定的业务处理。首先简单介绍下cas实现的原理（详细的cas知识，请自行google了解）。
1、cas的核心思想是基于客户端cookie服务共享机制。
2、cas两个核心对象tgt，st。tgt是cas封装了客户端的cookie对象，写入浏览器客户端的cookie。st是cas服务端为每一个cas客户端创建的一个票据。
3、所有的客户端服务的登录认证均跳转至cas服务端，cas服务端通过tgt判断用户是否完成登录验证。若没有tgt，则会到登陆页要求用户输入信息验 证，验证成功之后，cas服务端会产生一个tgt对象，并写到浏览器客户端。同时为对应的服务创建st，并作为参数跳转回请求认证的服务。对应的服务获取 到st，再次到cas服务端验证st的有效性，若有效，即允许访问服务。
以上简单介绍了cas的实现原理和流程，那么在需要https全程访问，我们就需要在st上下功夫。
通过分析cas的源码可以发现，cas在验证成功之后，跳转到对应的服务时，是根据请求的参数service，而同时其内部优先支持目标服务 （targetservice）参数，因此我们采用了在登录验证时，若选择全程ssl保护，则会携带targetservice参数引导cas服务端跳转 到targetservice（验证成功之后），并且以targetservice生成st。其中参数targetservice参数即我们每一台服务器 https配置serverhost，这一步是关键。
完成上述targetservice（https）的引导，即成功引导用户使用https访问邮局服务。
三、实现多个服务切换之后，切入邮局系统，仍然保持https访问。
我们主要采用了cookie机制，当然你也可以采用session机制，条条大道通罗马。在cas服务端验证请求时，我们会根据 用户的选择，记录当前是否https全程访问到cookie中，注意此时的cookie，我们会记录到邮局服务下（而并非cas服务下），并且是根目录， 有效期设置为浏览器的会话时效。这样，当用户切换不同服务之后，切回邮局，我们才能记住当前用户的ssl保护状态。
四、最后，谈谈https访问邮局服务过程，出现的一些问题。浏览器安全限制的问题，在ie8版本以下，https应用下，若是访问http资源，则浏览器会提示安全限制。这个真的很影响用户的交互，你怎么看？必须解除。
因为三五邮局已经是一个非常庞大、成熟的系统，当然内部不免某些配置http的资源，这就决定了我们接下来的工作是，消除系统内部所有的这些http请 求。一是尽量把所有的资源请求路径相对化，采用相对路径；二是对于无法相对化的请求，尽量在客户端采用获取servername的方式来替代；当然，还有 一些外部系统嵌套的，那就要保证它也支持https咯，实在没办法的话，那就只能忍痛割爱。
以上为个人整个ssl保护实现的愚见，供诸君吐槽。
【说明】：本文章由站长整理发布，文章内容不代表本站观点，如文中有侵权行为，请与本站客服联系(QQ:)！