框架版本:
Spring security版本: spring-security-3.1.4.RELEASE
Tomcat 版本: apache-tomcat-6.0.37
浏览器:均支持Http/1.0 | 1.1
场景描述:
在使用spring security安全验证框架的时候会遇到类似的下列的情况:
登录页面使用户首次登录也是服务器端首次授权的地方,需要使用HTTPS形式进行加密传输,由于考虑性能的问题其余资源(例如页面)均使用HTTP访问.
问题:
在使用Spring Security配置两种方式自动切换,但是在切换的时候会碰到当你登录成功之后却不能进入主页,从中可能至少有3个sessionId,也就是说SessionId丢失了.
一.分析登录页面HTTP切换到HTTPS:
说明:请见下图:
由上图整个从chrome 浏览器调试中查看的整个登录请求过程图,可以看见整个请求过程当中从第二次重写URL之后sessionId一直是第一次分配的,切换到https之后并没有重新创建session,那么session在登录的时候又怎么会丢失咧?
二.分析登录整个请求过程:
?提交登录表单到服务器
?服务器返回302 登录成功跳转到主页
问题2.1此处sessionId为何登录成功却改变了??
大家有发现这里的sessionId改变了,就会问,为啥登录成功了却session改变了,这是由于Spring Security 提供的SessionFixationProtectionStrategy,防止会话固定攻击策略, 简单描述一下:
就是在用户登录成功之后重新创建一个session,并将登录前匿名会话强制失效,Spring Security默认即可防止会话固定攻击
关于Spring Security如何放置会话固定攻击详细请见: https://www.doczj.com/doc/c711773778.html,/makemelaugh/archive/2013/05/12/3074486.html
问题2.2 此处的Cookie值为何结尾处有”Secure”,为何平常请求中没有此字段?
如果cookie结尾有字符Secure代表此Cookie只能在HTTPS连接中被浏览器传递到服务器端进行会话验证,如果是HTTP连接则不会传递该信息
?登录成功,请求主页(注意:此处是HTTP形式请求)
问题:3.1此处为何丢失了session?
由于登录时使用的是https的连接,返回重定向客户端指令302时是以https形式返回,cookie中结尾中带有Secure字符,代表只能是在HTTPS连接时将Cookie发送至服务器端做会话验证,但是由于重定向到主页时是以HTTP(http://192.168.2.116/security/)去请
求,所以客户端请求主页的时候不会将登录成功后返回的Cookie从Http连接中传递到服务端做会话验证,那么此时服务器就会重新创建会话,然后跳转到登录页面重新登录
?由于服务器未能收到Cookie值,所以不能判断此用户是登录的,便重新创建Session并返回302跳转到Http形式的登录页此时URL是重写的形式的.
?请求Http形式的登录页面.
?服务器响应302跳转到HTTPS形式登录页,此时的sessionId是重写的上一次请求的. ?请求HTTPS登录首页.
?返回HTTPS登录首页
三.解决方案
描述:
问题就出在Https提交登录信息之后,登录成功了,返回了Cookie ,但是Cookie的结尾处标识了Secure,只能是HTTPS的连接才能将此Cookie发送到服务器,但是重定向的却是HTTP形式的主页,所以没能将Cookie信息发送至服务器,导致登录成功,却不能跳转到首页,如果我们在登录成功后自己实现重写URL在URL结尾处添加jsessionId就能解决此问题.
3.1编写一个Java类如下所示:
3.2修改配置文件
https://www.doczj.com/doc/c711773778.html,集群中保持session状态 https://www.doczj.com/doc/c711773778.html,提供了Session对象，从而允许程序员识别、存储和处理同一个浏览器对象对服务器上某个特定网络应用程序的若干次请求的上下文信息。Session对应浏览器与服务器的同一次对话，在浏览器第一请求网络应用程序的某个页面时，服务器会触发Session_onStart 事件；在对话超时或者被关闭的时候会触发Session_onEnd 事件。程序员可以在代码中响应这两个事件来处理与同一次对话相关的任务，如开辟和释放该次对话要使用的资源等。 在https://www.doczj.com/doc/c711773778.html,的程序中要使用Session对象时，必须确保页面的@page指令中EnableSessionState属性是True或者Readonly，并且在web.config文件中正确的设置了SessionState属性。 https://www.doczj.com/doc/c711773778.html,中Session的状态保持是由web.config文件中的 https://www.doczj.com/doc/c711773778.html, Session详解及Session莫名丢失的原因及解决办法 作者:YanJun 日期:2007-07-29 字体大小: 小中大 Session模型简介 Session是什么呢？简单来说就是服务器给客户端的一个编号。当一台WWW服务器运行时，可能有若干个用户浏览正在运正在这台服务器上的网站。当每个用户首次与这台WWW服务器建立连接时，他就与这个服务器建立了一个Session，同时服务器会自动为其分配一个SessionID，用以标识这个用户的唯一身份。这个SessionID是由WWW服务器随机产生的一个由24个字符组成的字符串，我们会在下面的实验中见到它的实际样子。 这个唯一的SessionID是有很大的实际意义的。当一个用户提交了表单时，浏览器会将用户的SessionID自动附加在HTTP头信息中，（这是浏览器的自动功能，用户不会察觉到），当服务器处理完这个表单后，将结果返回给SessionID所对应的用户。试想，如果没有SessionID，当有两个用户同时进行注册时，服务器怎样才能知道到底是哪个用户提交了哪个表单呢。当然，SessionID还有很多其他的作用，我们会在后面提及到。 除了SessionID，在每个Session中还包含很多其他信息。但是对于编写ASP或https://www.doczj.com/doc/c711773778.html,的程序与来说，最有用的还是可以通过访问ASP/https://www.doczj.com/doc/c711773778.html,的内置Session对象，为每个用户存储各自的信息。例如我们想了解一下访问我们网站的用户浏览了几个页面，我们可能在用户可能访问到每个的页面中加入： <% If Session("PageViewed") = ""Then Session("PageViewed") = 1 Else Session("PageViewed") = Session("PageViewed") + 1 End If %> 通过以下这句话可以让用户得知自己浏览了几个页面： Session对象失效的客户端解决方法 魏莹李锋冯珊 问题的提出 ASP（Active Server Pages）技术的Session对象用于存储用户在对话期间的私有信息。当前用户的Session对象中定义的变量和对象能在页面之间共享，但是不能为应用中其他用户所访问，因此在用ASP开发网络应用程序时，可以利用Session对象保存和跟踪用户的状态信息。 Session对象有一个十分重要的属性：Timeout，它用于设置在会话资源被释放前，会话对象所能保持非活动状态的时间（默认值为20分钟）。当Timeout属性设置的时间值耗尽后，会话资源将被释放。通过Timeout属性破坏Session对象，避免了Session对象在服务器中无限制地产生，保护了服务器资源。但是，在实际网络开发中，常常遇到由于Session对象失效，用户状态信息丢失而导致应用流程无法正常完成的问题。 虽然利用Timeout属性释放资源的策略是出于保护服务器的目的，但是Session对象不可预知的失效性，却成为开发应用程序的一个弊病。因而在实际应用程序的开发中，必须解决Session对象失效的问题。 传统的解决方法 现有的解决方法都是采用服务器端方法解决Session对象失效问题。典型的处理方法分为两大类：失效前的处理和失效后的处理。 失效前的处理是指在Session对象尚未失效之前，对变量进行转存等处理，做到防患于未然。典型的解决方法是在应用程序中设定一个定时器，在Session对象失效前5分钟触发定时器，然后重新设置Session对象的各个变量和对象。由于必须在服务器端实时维护该定时器，并且必须保证该段程序在整个会话过程中处于激活状态，所以采用这种方法增加了服务器的额外负载。 失效后的处理是指在Session对象失效后，立即提示用户进行处理。典型的解决方法是在Session对象失效后，在服务器端保存断点，并提示用户重新登录，继续完成工作。这种方法实现简单，但是往往因为断点的不可完全自动恢复性，以及重新登录过程的复杂性，而受到最终用户的抱怨和指责。 针对以上两类解决方案的缺陷，笔者在编程实践中结合Cookie对象的特性，采用Session 对象与Cookie对象在客户端联合存取会话级变量的方法，既避免了对服务器资源的额外需求，又解决了断点不可自动恢复的问题，而且还免去了重新登录的麻烦。 新的解决方法 Cookie对象是用来存储有关当前用户数据的小信息包，它可以在浏览器和Web服务器之间传递。在Web应用中，Cookie提供了一种用于跟踪、记录每个用户位置的机制。Cookie 最常见的用处之一，就是保存一个Web应用中最后一次被访问的网络页面的时间以及日期或被访问的网址。 通常，Cookie对象在客户端Windows系统目录下Cookies子目录中以文件形式存储。存储在Cookie对象中的信息数据能够被保存较长时间，所以，可以将会话级变量备份在Cookie 对象中，在Session对象失效后，通过检索并利用Cookie对象中的信息来自动恢复断点。Cookie对象具有如下几个属性： ●Expires：设定Cookie对象到期的日期； ●Domain：将Cookie对象的传送确定为仅由Domain属性确定的成员； ●Path：确定Cookie对象传送路径； ：利用Wireshark软件进行数据包抓取 1.3.2 抓取一次完整的网络通信过程的数据包实验 一，实验目的： 通过本次实验，学生能掌握使用Wireshark抓取ping命令的完整通信过程的数据包的技能，熟悉Wireshark软件的包过滤设置和数据显示功能的使用。 二，实验环境： 操作系统为Windows 7,抓包工具为Wireshark. 三，实验原理： ping是用来测试网络连通性的命令，一旦发出ping命令，主机会发出连续的测试数据包到网络中，在通常的情况下，主机会收到回应数据包，ping采用的是ICMP协议。 四，验步骤： 1.确定目标地址：选择https://www.doczj.com/doc/c711773778.html,作为目标地址。 2.配置过滤器：针对协议进行过滤设置，ping使用的是ICMP协议，抓包前使用捕捉过滤器，过滤设置为icmp,如图 1- 1 图 1-1 3.启动抓包：点击【start】开始抓包，在命令提示符下键入ping https://www.doczj.com/doc/c711773778.html,, 如图 1-2 图 1-2 停止抓包后，截取的数据如图 1-3 图 1-3 4，分析数据包：选取一个数据包进行分析，如图1- 4 图1-4 每一个包都是通过数据链路层DLC协议，IP协议和ICMP协议共三层协议的封装。DLC协议的目的和源地址是MAC地址，IP协议的目的和源地址是IP地址，这层主要负责将上层收到的信息发送出去，而ICMP协议主要是Type和Code来识别，“Type:8,Code：0”表示报文类型为诊断报文的请求测试包，“Type:0,Code:0”表示报文类型为诊断报文类型请正常的包。ICMP提供多种类型的消息为源端节点提供网络额故障信息反馈，报文类型可归纳如下： （1）诊断报文（类型：8，代码0；类型：0代码：0）； (2）目的不可达报文（类型：3，代码0-15）； （3）重定向报文（类型：5，代码：0--4）； （4）超时报文（类型：11，代码：0--1）； （5）信息报文（类型：12--18）。 HTTPS请求 package com.sunzk.dreamsunlight.weixin.util; import java.io.BufferedReader; import java.io.InputStream; import java.io.InputStreamReader; import java.io.OutputStream; import https://www.doczj.com/doc/c711773778.html,.ConnectException; import https://www.doczj.com/doc/c711773778.html,.URL; import https://www.doczj.com/doc/c711773778.html,.ssl.HttpsURLConnection; import https://www.doczj.com/doc/c711773778.html,.ssl.SSLContext; import https://www.doczj.com/doc/c711773778.html,.ssl.SSLSocketFactory; import https://www.doczj.com/doc/c711773778.html,.ssl.TrustManager; import net.sf.json.JSONException; import net.sf.json.JSONObject; import org.apache.log4j.Logger; import com.sunzk.dreamsunlight.weixin.certificate.MyX509 TrustManager; import com.sunzk.dreamsunlight.weixin.model.Menu; import com.sunzk.dreamsunlight.weixin.token.AccessToken; /** * * @ClassName: WeiXinHttpsUtil * * @Description: TODO(微信HTTPS请求工具类) * * @author sunzk-dreamsunlight-QQ(1131341075) * * @date 2016-11-14 上午10:05:56 * */ public class WeiXinHttpsUtil { 分布式Session共享 概念 不同进程之间的session共享访问。 解决了分布式系统或者系统集群部署时出现的问题：web容器（如tomcat）管理的session都存放于本地内存中无法共享，用户每次访问的服务器可能都不一样，因此出现服务器不能识别用户、用户登录状态失效等。 解决方案： 方案一：黏性session NGINX等负载均衡网关，可以通过hash映射等方式，保证相同用户的请求会转发到同一台服务器。 优点：简单高效，易实施。 缺点：存在大量请求转发到单点服务器极端情况导致负载均衡失效；单点故障导致用户session丢失。 方案二：tomcat集群session复制 Tomcat提供集群环境下的session复制功能，以达到session共享。 优点：无开发工作量。 缺点：session复制会消耗大量服务器资源，只能应用于小规模的集群。 方案三：Spring session + redis（推荐） Spring session可以接管web容器的session管理，并可以将session 数据存放于redis等第三方存储。 优点：Spring boot/cloud项目无缝集成；可存储海量session数据；可以利用redis提供的持久化保证宕机恢复、服务升级重启用户session不丢失；很好的支持服务在线扩容！ 缺点：Spring session没有多语言版本，限制了微服务框架下不同的技术选型。 Spring boot/cloud下的使用方法： 1.增加配置redis和spring session的配置 spring.redis.host=127.0.0.1 spring.redis.password=123456 spring.redis.port=6379 使用wireshark分析HTTPS流程的建立 使用wireshark分析HTTPS流程的建立 摘要: https流程 一、概要 为了网站以及用户的安全性，现在很多的网站都是https，大家都知道tcp通过三次握手建立连接，并且还有很多的同学对https连接建立的流程不太明白，包括我自己，通过借助于wireshark这种抓包工具，我们可以尝试着了解一下大概的流程。 （图1） 本图是客户端（10.0.45.103）访问服务端（114.215.88.85）通过wireshark 抓包显示出来的双方交互数据，访问是通过https访问服务器上的一台nginx 服务器服务。请关注第一列的No。下文中很多时候会用no表示一次交互。 图中可以很明显的看出tcp的三次握手以及之后的TLS加密流程的建立。二、tcp的三次握手 通过流程图可以看出（也可以看图1 的19368到19370这三个编号），首先客户端向服务端发起一个SYN的请求，序号(Seq)为0，确认号（ACK）也为0，这代表是本次是由客户端发起的首次请求。本次请求的数据长度为0 然后服务端给客户端响应，此时服务端的Seq也是0，值得是服务端的第一回应，并且给客户端说，你的请求我已经收到了（ACK=1）， 最后返还给客户端以后，客户端的序号+1，并且对服务端的响应做出确认，最后回给服务端，此时ACK=1，Seq=1 tcp的握手过程建立成功。 三、ssl连接的建立 通过以上可以看出，SSL也是建立在TCP的基础上的，经过tcp的三次握手，接下来才是加密信道的建立。 客户端和服务端建立安全连接大致经过以下几个步骤 1.客户端：ClientHello 2.服务端：Server Hello，Server certificate，Server Exchange，Server Hello Done 3.客户端：client Exchange 4.客户端：Application Data 5.服务端：New Session 6.服务端：Application Data 接下来看这几个步骤中具体的每一个步骤传输的内容 ClientHello client首先给服务端打招呼，对服务端说hello 应用层没什么特别的 分布式环境下session的存储的几个解决方案企业级应用系统很少是部署在单台服务器上的，这样就带来了跨服务器如何进行session共享的问题，笔者提供了两种方案，分别适用于两种不同场合，持久化session适合于高可靠性的环境，性能上可能有所损坏，而基于memcache 的解决方案相对来说性能较好，但一旦memcache重启，数据丢失。 分布式session之持久化 以mysql举例 1.建立数据库 Sql代码 1.create database session_persistence; 2. https://www.doczj.com/doc/c711773778.html,e session_persistence; 4. 5.create table session( 6. session_id varchar(100) NOT NULL, 7. valid_session char(1) NOT NULL, 8. max_inactive int(11) NOT NULL, 9. last_access bigint(20) NOT NULL, 10. app_name varchar(255) DEFAULT NULL, 11. session_data mediumblob, 12.primary key (session_id), 13.KEY kapp_name (app_name) 14.) engine=InnoDB default charset=utf8; 注:表的字段必须和下面的配置对应 2.配置tomcat的context.xml Xml代码 1. https://www.doczj.com/doc/c711773778.html, Session详解 阅读本文章之前的准备 阅读本文章前，需要读者对以下知识有所了解。否则，阅读过程中会在相应的内容上遇到不同程度的问题。 ?懂得ASP/https://www.doczj.com/doc/c711773778.html,编程 ?了解ASP/https://www.doczj.com/doc/c711773778.html,的Session模型 ?了解https://www.doczj.com/doc/c711773778.html, Web应用程序模型 ?了解https://www.doczj.com/doc/c711773778.html, Web应用程序配置文件Web.config的作用、意义及使用方法 ?了解Internet Information Services(以下简称IIS)的基本使用方法 ?了解如何在Microsoft SQL Server中创建一个数据库。 Session模型简介 Session 是什么呢？简单来说就是服务器给客户端的一个编号。当一台WWW服务器运行时，可能有若干个用户浏览正在运行在这台服务器上的网站。当每个用户首次与这台WWW服务器建立连接时，他就与这个服务器建立了一个Session，同时服务器会自动为其分配一个SessionID，用以标识这个用户的唯一身份。这个SessionID是由WWW服务器随机产生的一个由24个字符组成的字符串，我们会在下面的实验中见到它的实际样子。 这个唯一的SessionID是有很大的实际意义的。当一个用户提交了表单时，浏览器会将用户的SessionID自动附加在HTTP头信息中，（这是浏览器的自动功能，用户不会察觉到），当服务器处理完这个表单后，将结果返回给SessionID所对应的用户。试想，如果没有SessionID，当有两个用户同时进行注册时，服务器怎样才能知道到底是哪个用户提交了哪个表单呢。当然，SessionID还有很多其他的作用，我们会在后面提及到。 除了SessionID，在每个Session中还包含很多其他信息。但是对于编写ASP或https://www.doczj.com/doc/c711773778.html,的程序与来说，最有用的还是可以通过访问ASP/https://www.doczj.com/doc/c711773778.html,的内置Session对象，为每个用户存储各自的信息。例如我们想了解一下访问我们网站的用户浏览了几个页面，我们可能在用户可能访问到每个的页面中加入： <% If Session("PageViewed") = ""Then Session("PageViewed") = 1 Else Session("PageViewed") = Session("PageViewed") + 1 End If 对于https协议的接口的抓包方法 一、使用fiddler 1.使用fiddler对浏览器访问的https接口抓包 默认设置下的fiddler是不能解密https协议的请求的内容的，在fiddler上抓到的https 协议的请求都是如下图所示，但是看不到其中的传参以及返回结果的内容： 如果想要用fiddler抓到浏览器访问的https接口，需要在fiddler做如下设置： a)进入菜单栏，Tools->Fiddler Options： b)切换到https选项卡，勾选如下选项： c)按照上面步骤勾选后，会弹出如下提示框，提示意思大概就是fiddler会生成 一个唯一的根证书，我们要配置Windows，使Windows信任这个CA证书， 所以点击Yes即可： d)点击Yes之后，Windows会马上弹出下面的弹窗，我们点击“是”，就能将 DO_NOT_TRUST_FiddlerRoot这个由fiddler生成的CA证书导入到浏览器，也就 完成了上面C步骤所述的配置Windows，使Windows信任这个CA证书的步 骤： 完成了上面的配置后，即可以在浏览器发起一个https协议的请求： 此时可以在fiddler抓到这个请求，并能看到传参内容和返回的内容 返回的内容： 2.使用fiddler对app访问的https接口抓包 首先要先在fiddler进行设置，步骤与上面的一样，但是不用导入证书到浏览器，这里不再赘述。 Android： 要使用fiddler抓到app发出的https请求，需要在app端安装fiddler生成的CA证书，在Android的app端安装fiddler生成的CA证书步骤如下： a)设置手机代理服务器，代理到自己的电脑： 几种session存储方式比较 1. 客户端cookie加密 这是我以前采用的方式，简单，高效。比较好的方法是自己采用cookie机制来实现一个session,在应用中使用此session实现。 问题：session中数据不能太多，最好只有个用户id。 参考实现：https://www.doczj.com/doc/c711773778.html, 2. application server的session复制 可能大部分应用服务器都提供了session复制的功能来实现集群，tomcat,jboss,was都提供了这样的功能。 问题： 性能随着服务器增加急剧下降，而且容易引起广播风暴； session数据需要序列化，影响性能。 如何序列化，可以参考对象的序列化和反序列化. 参考资料 Tomcat 5集群中的SESSION复制一 Tomcat 5集群中的SESSION复制二 应用服务器－JBoss 4.0.2集群指南 3. 使用数据库保存session 使用数据库来保存session,就算服务器宕机了也没事，session照样在。 问题： 程序需要定制； 每次请求都进行数据库读写开销不小(使用内存数据库可以提高性能，宕机就会丢失数据。可供选择的内存数据库有BerkeleyDB,MySQL的内存表); 数据库是一个单点，当然可以做数据库的ha来解决这个问题。 4. 使用共享存储来保存session 和数据库类似,就算服务器宕机了也没事，session照样在。使用nfs或windows文件共享都可以,或者专用的共享存储设备。 问题： 程序需要定制； 频繁的进行数据的序列化和反序列化，性能是否有影响； 共享存储是一个单点，这个可以通过raid来解决。 5. 使用memcached来保存session 这种方式跟数据库类似，不过因为是内存存取的，性能自然要比数据库好多了。 问题： 程序需要定制,增加了工作量； 存入memcached中的数据都需要序列化，效率较低； memcached服务器一死，所有session全丢。memchached能不能做HA 我也不知道，网站上没提。 参考资料 应用memcached保存session会话信息 正确认识memcached的缓存失效 扩展Tomcat 6.x，使用memcached存放session信息 6. 使用terracotta来保存session https://www.doczj.com/doc/c711773778.html,将Session保存到数据库中 因为https://www.doczj.com/doc/c711773778.html,中Session的存取机制与ASP相同，都是保存在进行中， 一旦进程崩溃，所有Session信息将会丢失，所以我采取了将Session信息保存到SQL Server中，尽管还有其它的 几个方式（本文不作介绍），要将Session保存到SQL Server中，需要有以下几个步骤： 1.首先要创建用于保存Session数据的数据库，以命令行的形式用aspnet_regsql.exe来完成，具体命令为 C:\WINDOWS\https://www.doczj.com/doc/c711773778.html,\Framework\v2.0.50727>aspnet_regsql.exe -ssadd -sstype c -d sd -E 该命令是以windows验证方式，添加了sd数据库保存session数据。 C:\Windows\https://www.doczj.com/doc/c711773778.html,\Framework\v4.0.30319 InstallSqlStateTemplate.sql 2.需要修改https://www.doczj.com/doc/c711773778.html, web.config文件中的SessionState结点，该结点位于 深入理解Servlet/JSP之“Cookie和Session原理” (2008-06-29 13:41:09) 转载 标签：it it培训 java jsp servlet session cookie session持久化 由于HTTP协议的无状态特征，Web应用中经常使用Cookie和Session来保存用户在与系统交互过程中的状态数据。下面通过分析HTTP协议对Cookie和Session的工作原理加以了解。 一、Cookie Cookie的含义是“服务器送给浏览器的甜点”，即服务器在响应请求时可以将一些数据以“键-值”对的形式通过响应信息保存在客户端。当浏览器再次访问相同的应用时，会将原先的Cookie通过请求信息带到服务器端。 下面的Servlet展示了Cookie的功能。 ... ... ... public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); String option = request.getParameter("option"); if ("show".equals(option)) { //获得请求信息中的Cookie数据 Cookie[] cookies = request.getCookies(); if (cookies != null) { //找出名称（键）为“cool”的Cookie for (int i = 0; i < cookies.length; i++) { if ("cool".equals(cookies[i].getName())) { out.println(" http 使用curl发起https请求 今天一个同事反映，使用curl发起https请求的时候报错：“SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed” 很明显，验证证书的时候出现了问题。 使用curl如果想发起的https请求正常的话有2种做法： 方法一、设定为不验证证书和host。 在执行curl_exec()之前。设置option $ch = curl_init(); ...... curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE); 方法二、设定一个正确的证书。 本地ssl判别证书太旧，导致链接报错ssl证书不正确。 我们需要下载新的ssl 本地判别文件 http://curl.haxx.se/ca/cacert.pem 放到程序文件目录 curl 增加下面的配置 curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,true); ; curl_setopt($ch,CURLOPT_CAINFO,dirname(__FILE__).'/cacert.pem'); 大功告成 （本人验证未通过。。。报错信息为：SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed） 如果对此感兴趣的话可以参看国外一大神文章。 https://www.doczj.com/doc/c711773778.html,/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected -sites/ 为了防止某天该文章被Q今复制过来。内容如下： Using cURL in PHP to access HTTPS (SSL/TLS) protected sites From PHP, you can access the useful cURL Library (libcurl) to make requests to URLs using a variety of protocols such as HTTP, FTP, LDAP and even Gopher. (If you’ve spent time on the *nix command line, most environments also have the curl command available that uses the libcurl library) In practice, however, the most commonly-used protocol tends to be HTTP, especially when usingPHP for server-to-server communication. Typically this involves accessing another web server as part of a web service call, using some method such as XML-RPC or REST to query a resource. For example, Delicious offers a HTTP-based API to manipulate and read a user’s posts. However, when trying to access a HTTPS resource (such as the delicious API), there’s a little more configuration you have to do before you can get cURL working right in PHP. The problem If you simply try to access a HTTPS (SSL or TLS-protected resource) in PHP using cURL, you’re likely to run into some difficulty. Say you have the following code: (Error handling omitted for brevity) // Initialize session and set URL. $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); // Set so curl_exec returns the result instead of outputting it. curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); // Get the response and close the channel. $response = curl_exec($ch); HTTP抓包分析 一：实验目的： 1、学习使用网络数据抓包软件Ethereal，对互连网进行数据抓包，巩固对所学知识的 理解 二：实验内容： 1、分析http协议请求的响应过程。 2、分析TCP的处理过程，HTTP，TCp的报文格式。 三：实验环境及工具 1、虚拟主机XP，虚拟网卡NAT，TCP/IP参数自动获取 2、安装Wireshark抓包软件 四：实验步骤 1、安装Wireshark，简单描述安装步骤。 2、打开wireshark，选择接口选项列表。或单击“Capture”，配置“option”选项。 3、设置完成后，点击“start”开始抓包，显示结果。 4、选择某一行抓包结果，双击查看此数据包具体结构 五：网络协议包数据分析 1：http请求报文分析（第8个包） 请求行：方法字段：GET，版本是http/1.1. 首部行：主机host：https://www.doczj.com/doc/c711773778.html,；Connection：Keep-Alive，即保持持久连接；Accept-language：zh-cn，即接收语言是中文。 2．http响应报文（第55个包） 状态行：http/1.1 200 OK；请求成功。 首部行：响应Date：sat，21，Apr 2012 04:58:18 GMT ;Content-Type：text/html 指示实体主体中的对象是text/html文本；Content-Length：35593 表明了被发送对象的字节数是35593个字节。 :3：TCP报文格式分析： 报文格式： 如截图可知：源端口号：80，目的端口号3968，序号：1，确认号：424，首部长度：20 bytes，Flags=0X10（URG=0，ACK=1，PSH=0，RST=0，SYN=0，FIN=0）接收窗口大小：65112；检验和：0x8a44。 4：TCP响应（3次握手）分析： 1）服务器应用启动,进入LISTEN状态； 2）客户端向服务器端发送一个TCP报文段，该段设置SYN标识，请求跟服务器端应用同步，之后进入SYN-SENT状态，等待服务器端的响应；（第5个包） 3）服务器端应用收到客户端的SYN 段之后，发送一个TCP段响应客户端，该段设置SYN和ACK标识，告知客户端自己接受它的同步请求，同时请求跟客户端同步。之后进入 SYN-RECEIVED状态；（第6个包） HTTPS的3种实现方法 . 分类：java 2010-04-30 10:17 164人阅读评论(0) 收藏举报 引用自：https://www.doczj.com/doc/c711773778.html,/blog/289650 文章如下：HTTPS实际是SSL over HTTP, 该协议通过SSL在发送方把原始数据进行加密，在接收方解密，因此，所传送的数据不容易被网络黑客截获和破解。本文介绍HTTPS的三种实现方法。 方法一静态超链接这是目前网站中使用得较多的方法，也最简单。 在要求使用SSL进行传输的Web网页链接中直接标明使用HTTPS协议，以下是指向需要使用SSL的网页的超链接：SSL例子需要说明的是，在网页里的超链接如果使用相对路径的话，其默认启用协议与引用该超链接的网页或资源的传输协议相同，例如在某超链接“HTTPS://192.168.100.100/ok/l ogin.jps”的网页中包含如下两个超链接：SSL链接非SSL链接那么，第一个链接使用与“HTTPS://192.168.100.100/ok/login.jsp”相同的传输协议HTTPS，第二个链接使用本身所标识的协议HTTP。 使用静态超链接的好处是容易实现，不需要额外开发。然而，它却不容易维护管理; 因为在一个完全使用HTTP协议访问的Web应用里，每个资源都存放在该应用特定根目录下的各个子目录里，资源的链接路径都使用相对路径，这样做是为了方便应用的迁移并且易于管理。但假如该应用的某些资源要用到HTTPS协议，引用的链接就必须使用完整的路径，所以当应用迁移或需要更改URL中所涉及的任何部分如：域名、目录、文件名等，维护者都需要对每个超链接修改，工作量之大可想而知。再者，如果客户在浏览器地址栏里手工输入HTTPS 协议的资源，那么所有敏感机密数据在传输中就得不到保护，很容易被黑客截获和篡改！ 方法二资源访问限制为了保护Web应用中的敏感数据，防止资源的非法访问和保证传输的安全性，Java Serv let 2.2规范定义了安全约束（Security-Constraint）元件，它用于指定一个或多个We b资源集的安全约束条件；用户数据约束（User-Data-Constraint）元件是安全约束元件的子类，它用于指定在客户端和容器之间传输的数据是如何被保护的。 用户数据约束元件还包括了传输保证（Transport-Guarantee）元件，它规定了客户机和服务器之间的通信必须是以下三种模式之一：None、Integral、Confidential。None表示被指定的Web资源不需要任何传输保证；Integral表示客户机与服务器之间传送的数据在传送过程中不会被篡改; Confidential表示数据在传送过程中被加密。大多数情况下，Integral或Co nfidential是使用SSL实现。 这里以BEA的WebLogic Server 6.1为例介绍其实现方法，WebLogic是一个性能卓越的J2 EE 服务器，它可以对所管理的Web资源，包括EJB、JSP、Servlet应用程序设置访问控制条款。 假设某个应用建立在Weblogic Server里的/mywebAPP目录下，其中一部分Servlets、JSPs要Session用法小结
Session对象失效的客户端解决方法
抓包实验
HTTPS请求工具类汇总
基于springcloud分布式session共享.docx
使用wireshark分析HTTPS流程的建立
分布式环境下session的存储的几个解决方案已发布
https://www.doczj.com/doc/c711773778.html, Session详解
https请求的抓包方法
几种session存储方式比较
Session保存到数据库
深入理解Session,cookie
" + cookies[i].getName() + ":" + cookies[i].getValue() + "
"); } } } } else if ("add".equals(option)) { //创建Cookie对象 Cookie cookie = new Cookie("cool", "yeah!");http 使用curl发起https请求
2.7 HTTP抓包分析
HTTPS的3种实现方法
相关主题
文本预览