session

Appium简介 Appium是一个开源、跨平台的测试工具，可以用来测试原生及混合的移动端应用。Appium支持IOS、Android及Windows 平台。Appium使用WebDriver的json wire协议，来驱动IOS系统的UIAutomation库、Android系统的UIAutomator框架。它允许测试人员在不同的平台（iOS，Android）使用同一套API来写自动化测试脚本，这样大大增加了iOS和Android测试套件间代码的复用性。下面的是为其官网上面的介绍： Appium is an open-source tool you can use to automate mobile native, mobile web, and mobile hybrid applications on iOS and Android platforms. “Mobile native apps” are those written using the iOS or Android SDKs. “Mobile web apps” are web apps accessed using a mobile browser (Appium supports Safari on iOS and Chrome on Android). “Mobile hybrid apps” have

案例1：构建memcached服务 1.1 问题 本案例要求先快速搭建好一台memcached服务器，并对memcached进行简单的增、删、改、查操作： 安装memcached软件，并启动服务 使用telnet测试memcached服务 对memcached进行增、删、改、查等操作 1.2 方案 memcached是高性能的分布式缓存服务器，用来集中缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的响应速度。访问拓扑如图-1所示。 使用1台RHEL7虚拟机作为memcached服务器（192.168.4.5）。 在RHEL7系统光盘中包含有memcached，因此需要提前配置yum源，即可直接使用yum安装，客户端测试时需要提前安装telnet远程工具。 验证时需要客户端主机安装telnet，远程memcached来验证服务器的功能： add name 0 180 10 / / 变量不存在则添加 set name 0 180 10 / / 添加或替换变量 replace name 0 180 10 / / 替换 get name / / 读取变量 append name 0 180 10 / / 向变量中追加数据 delete name / / 删除变量 stats / / 查看状态 flush_all / / 清空所有 提示：0表示不压缩，180为数据缓存时间

1.概念 session时服务器会话技术， 在一次会话 的多次请求间共享数据，将数据保存在服务端的对象HttpSession中，是一个域对象 2.使用 HttpSession接口中有几个方法： void setAttribute(String var1, Object var2); Object getAttribute(String var1); void removeAttribute(String var1); 以下是使用的具体过程： 输出结果为 hello session 在这里提一下req.getSession() HttpSession为一个接口，且没有任何实现类，获取session是通过request获取 来看一下request内的方法 HttpSession getSession ( ) ; 是一个空实现，我们再来打印一下session： org . apache . catalina . session . StandardSessionFacade @17e49b93 结果发现session对象的创建与request和response一样，是由tomcat内部创建 在这里列出getSession（）的用法： 有参：true或false true:HttpServletRequest.getSession(ture) :参数为true时，若存在会话，则返回该会话

本篇继续对于安全性测试话题，结合DVWA进行研习。 Session Hijacking用户会话劫持 1. Session和Cookies 这篇严格来说是用户会话劫持诸多情况中的一种，通过会话标识规则来破解用户session。 而且与前几篇不同，我们有必要先来理解一下Session和Cookie的工作机制。 实际上要谈论这两个小伙伴，又要先理解http协议的运作机制，这样讨论下去可就篇幅太长了。 我们只需要了解以下事实： http协议是无状态的 就好像两个人用老式的手摇电话机通电话。每一次http请求和数据交换就像这样的一次电话通话过程，当请求完毕以后，再进行下一次请求时，http协议是无法追踪上一则通话记录的。这样每一次用户与服务器的交互都是独立的一次通话，对于一个web应用而言显然是存在问题的，因为用户的请求十有八九具有连续性。就比如一个用户在商城添加了某商品到购物车，当他去结账时，又是一次新的请求，他的购物车http协议仅仅通过连接状态是无法追踪的！ Session：来来来 给你分配个号码牌 为了解决用户的接续访问问题，一个简单的想法就是，将每一次用户与服务器之间的持续通话做为一个“会话”存放在服务器端。 当用户第一次打call进来的时候，你先别说话，先给你个小牌牌，这个小牌牌就用来做为这次用户会话的跟踪。 在我们的应用内通常使用sessionID或者类似的形式进行记录。

CSRF即Cross Site Request Forgery（跨站点请求伪造）。 用户在客户端（浏览器）上任何一个操作如提交表单、点击超链接、或者是页面资源的显示都是向服务器发起请求 而得以实现的，所以攻击者往往都是可以通过模拟真实用户的请求来“代替”用户完成操作的。 例如A用户删除id为18的文章的请求地址为：www.eco.com/delete?id=18 那么攻击者可以构造一个html页面，页面中有这样一段代码： *** <img src="http://www.eco.com/delete?id=18" /> *** （当然，用户会看到一张无法显示的图片） 然后引导A用户去访问攻击者的这个html页面，A用户看到了这样一张无法显示的图片，然后回到自己的博客，一看， 自己的id为18的文章不翼而飞了，这，就是跨站点请求伪造。当然了，CSRF肯定不会这么轻易就能成功的，因为大多 数web项目都会对http请求设置一个过滤器，用来验证发出请求的用户身份，使得CSRF的实施变得麻烦起来。 1.浏览器的cookie策略 我应该不止一次地说过，用户注册之后，会设置一个cookie（token）返回给客户端（浏览器），用于之后请求的身份 验证。 浏览器所持有的cookie分为两种，一种是“Session Cookie”、一种是“Third-party Cookie

背景知识：Authentication和Authorization的区别： Authentication：用户认证，指的是验证用户的身份，例如你希望以小A的身份登录，那么应用程序需要通过用户名和密码确认你真的是小A。 Authorization：授权，指的是确认你的身份之后提供给你权限，例如用户小A可以修改数据，而用户小B只能阅读数据。 由于http协议是无状态的，每一次请求都无状态。当一个用户通过用户名和密码登录了之后，他的下一个请求不会携带任何状态，应用程序无法知道他的身份，那就必须重新认证。因此我们希望用户登录成功之后的每一次http请求，都能够保存他的登录状态。 目前主流的用户认证方法有基于token和基于session两种方式。 基于session的用户认证 基于session的认证流程如下： 用户输入其登录信息 服务器验证信息是否正确，并创建一个session，然后将其存储在数据库中 服务器为用户生成一个sessionId，将具有sesssionId的Cookie将放置在用户浏览器中 在后续请求中，会根据数据库验证sessionID，如果有效，则接受请求 一旦用户注销应用程序，会话将在客户端和服务器端都被销毁 基于token（令牌）的用户认证 最常用的是JSON Web Token（jwt）： 用户输入其登录信息 服务器验证信息是否正确，并返回已签名的token

问题描述： 情形一：有服务器A与B（A、B服务器不在同一域中），服务器A中的页面包含有iframe，需要加载B服务器中的数据（需要登录验证后的）。验证信息从iframe的src属性中传递给服务器B，当服务器B收到请求后，先写session，然后再继续此次请求。当iframe中页面加载完成后，页面中有其它请求发到服务器B（这些请求都是需要验证通过后，才能继续）。iframe中的请求发送到服务器B时，没有session，导致请求失败。 情形二： 有服务器A与B （A、B服务器不在同一域中） ，服务器A中的页面先发起验证，再进入其它请求； 解决办法： 服务器B的返回中加入： response.setHeader("P3P","CP=CAO PSA OUR") 问题原因： cookie与session跨域登陆代码(ie6,ie7,firefox)frameset里面，也就是里面的frame是来自第三方站点(不同ip或不同域名)，那么默认情况下ie会自动禁用这些站点的cookie，也就是在请求某url时在http header里不发送它们的cookie，包括session的cookie。注意，这些站点在response里面设置的cookie还是会被发送到浏览器的。 但像ie 6.0和ie 7.0有个自己的标准.要支持p3p,ie 6的缺省隐私等级设置为"中"——即

1、IE浏览器iframe跨域丢失Session问题 在开发中，我们经常会遇到使用Frame来工作，而且有时是为了跟其他网站集成，应用到多域的情况下，而Iframe是不能保存Session的因此，网上可以找到很多相关的文章，如果网站可以采用设置Web.Config中的配置： mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="40" /> 把cookieless="false"改成"true"就可以了但也同样有个小问题，就是如果页面中采用Javascript的window.location.href=''这样的方式来重定向的话，系统会认为这是另一个新的请求，产生一个新的SessionId，导致原Session同样的丢失所以对于重定向，还是使用Response.Redirect()为好 除了Ifrmae有丢Session问题外，frameset也有同样的问题Frameset的问题更不确定，是有时会丢，有时不会丢，这更认人头痛，在网上找到了一个方法，在页面page_onload里添加一语句： Response

再一次被网上那些教程误导后决定自己写一个。真心被那些奇怪的教程误导了好几次，之前研究其它东西的时候也是。蛋疼啊。 安装redis 直接用apt-get命令即可 sudo apt-get install redis-server 安装的时候会询问你一个东西，输入Y就行。 安装完后会自动启动redis的服务，可以通过下面命令来查看进程是否已经启动。 ps -aux|grep redis 然后检查下redis服务的状态，看看是不是runing。 redis-server is running 安装PHP扩展 使用apt-get就可以安装了 sudo apt-get install php5-redis 然后重启下apache service apache restart CI的session中使用redis存储 在CI 3.0（2.0是不支持用redis存储session）的application\config\config.php中的两个配置改成下面这样 $config['sess_driver'] = 'redis'; $config['sess_save_path'] = 'tcp://127.0.0.1:6379'; 来源： oschina 链接： https://my.oschina.net/u/1860083/blog/468825

在网站群的建设中，各子站需要共享主站的footer等公共信息。同时主站的后台管理也集成了各子站的管理，采取的方式是使用 iframe 嵌入各站的页面。在本机开发环境中，没有出现任何的问题。但是一放到测试环境中，便遇到 session 丢失的问题。 环境：应用服务器采用tomcat6.0，各个站点单独使用一个应用服务器，部署在一台物理服务器上。外部访问采用同一个IP，但是不同的端口。 起初以为，IE它的安全策略默认是会把iframe中的页面站点认为是不可信任的，它会阻止该站点传过来的 cookie （如果你在iframe中的URL跳转是用的localhost,则不会被阻挡），所以因为没法使用cookie了，session便失效了。解决的方法是在过滤器，或者被嵌入的页面内加入属性为P3P的header信息。 java 为：response.addHeader("P3P","CP=CAO PSA OUR");但是依然没有成功。网上的解决方案都是这么说，况且自己以前还弄过，都成功过，这次怎么弄都不好。 今天脑子安静下来，仔细的分析这里面的原因。如果是IE的安全限制，但是火狐、google浏览器没有这样的限制，为什么这两个浏览器也出现这样的情况。这肯定不仅仅和跨域引起的P3P的安全问题有关。于是在本机测试，通过iframe引入测试环境中的链接，设置了P3P，发现一切正常。这就更说明了