session

转自：http://book.51cto.com/art/201405/439557.htm 先来看一下什么是Session。 用户使用网站的服务，基本上需要浏览器与Web 服务器的多次交互。HTTP 协议本身是无状态的，需要基于HTTP 协议支持会话状态（Session State）的机制。而这样的机制应该可以使Web 服务器从多次单独的HTTP 请求中看到“会话”，也就是知道哪些请求是来自哪个会话的。具体实现方式为：在会话开始时，分配一个唯一的会话标识（SessionId），通过Cookie 把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识来告诉Web 服务器请求是属于哪个会话的。在Web 服务器上，各个会话有独立的存储，保存不同会话的信息。如果遇到禁用Cookie 的情况，一般的做法就是把这个会话标识放到URL 的参数中。我们可以通过图2-8 来看一下上述过程。 当我们的应用服务器从一台变到两台后，如同图2-7 中的结构，我们就会遇到Session的问题了。具体是指什么问题呢？ 我们来看图2-9，当一个带有会话标识的HTTP 请求到了Web 服务器后，需要在HTTP请求的处理过程中找到对应的会话数据（Session）。而问题就在于，会话数据是需要保存在单机上的。 在图2-9 所示的网站中，如果我第一次访问网站时请求落到了左边的服务器，那么我的Session

单点登录（SSO)概述 概念：简单点说就是，用户只需要登录一次就可以访问所有相互信任的应用系统。 SSO体系结构： 1.认证中心 2.用户与账号系统、用户数据获取接口 3.客户端模块即授权验证（用户请求系统时，首先要对请求进行拦截） 4.令牌（token） 可以看作钥匙 SSO认证流程：工作原理和工作过程 1.浏览器发起访问系统的请求 2.客户端模块对用户请求进行拦截 3.验证token是否存在（不存在时重定向到登陆界面） 4.token存在时验证token是否有效（有效时可以访问系统） 5.token无效时重定向到登陆界面 6.进入登录界面，登录成功后进行授权（授权失败时提示授权失败） 7.授权成功则生成token令牌 8.生成token之后，再次返回到资源请求后重新再次进行验证 SSO相关核心技术： 1.HTTP协议的基础知识（无状态的协议） HTTP处理的一般分为三个步骤：接收请求、处理请求、返回结果。 因为HTTP是无状态的，所以无法判断第二个问题中问的是什么多少钱一支。 由于以前浏览器的请求都是用于请求的静态的资源，为了保持请求的高效，所以将HTTP设为了无状态，但随着不断的发展，HTTP无状态的已经无法处理更多的问题了，所以就需要对会话的维持： cookie：每次网络请求中，服务端返回给每个请求的唯一标识，每次发请求时会被传送【客户端】 session

一. 何为session 用户使用网站的服务，基本上需要浏览器和web服务器进行多次交互，web服务器如何知道哪些请求是来自哪个会话的？ 具体方式为：在会话开始时，分配一个唯一的会话标识(sessionId)，通过cookie把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识来告诉web服务器请求是属于哪个会话的。 如果遇到禁用cookie的情况，一般的做法就是把这个会话标识放到url的参数中。 二. 问题 因为会话信息保存在单机上，当我们的应用服务器从一台变成两台后，我们就会遇到session的问题了！ 当我们第一次访问网站时请求落到了A服务器，那么我的session就创建在A服务器上了，如果我们不做处理，就不能保证接下来的请求每次都落在同一台服务器上了，这就是session问题。 三. 解决办法： 1. session sticky 在web服务器变成多台后，如果我们可以保证同一个会话请求都能在同一个web服务器上处理，那么对于这个会话个体来说，和单机的情况是一样的。这就需要负载均衡器能够根据每次请求的会话标识来进行请求转发。 有何问题： ① 如果有一台web服务器宕机或重启，那么这台机器上的会话数据会丢失 ② 负载均衡器变成了一个有状态的结点，要保存会话到具体web服务器的映射，要消耗一定的内存。 2. session replication

SSO，Single Sign On，也就是单点登录，保证一个账户在多个系统上实现单一用户的登录 现在随着网站的壮大，很多服务会进行拆分，会做SOA服务，会使用dubbo做微服务，或者简单的小型分布式， 这样在服务与服务之间，或者系统与系统之间都是通过HTTP或者restful来进行通信的， 在以往的单系统应用中，我们都是把user存入session中的，需要用到的时候随时取，如果取不到就跳转到登录注册页面，非常简单的原理 但是在现如今的分布式应用中，如何保证session同步呢？ 比如订单服务是在 order.jd.com 购物车服务在 cart.jd.com 那么这2个二级域名下的用户信息如何实现同步呢？ 解决方案： 1. tomcat有一个session同步方案，就是一个传播机制，打个比方有A B C 3台tomcat，这3台tomcat的user信息都在session中并且保持一致，如果其中一台的user信息变化了，那么就会传播至另外两台，则实现同步，这样做没问题，但是仅仅只是在做tomcat集群的时候tomcat很少的时候会用，一旦集群增大，有100台，那么就互相传播吧，传播是需要性能损耗的，那么整个网站的性能就会被拉低，你的网站在你的网络风暴中就会晕死 2. nginx 非粘性session，说穿了就是一个session绑定传播

Cookie的由来 大家都知道HTTP协议是无状态的。 无状态的意思是每次请求都是独立的，它的执行情况和结果与前面的请求和之后的请求都无直接关系，它不会受前面的请求响应情况直接影响，也不会直接影响后面的请求响应情况。 一句有意思的话来描述就是人生只如初见，对服务器来说，每次的请求都是全新的。 状态可以理解为客户端和服务器在某次会话中产生的数据，那无状态的就以为这些数据不会被保留。会话中产生的数据又是我们需要保存的，也就是说要“保持状态”。因此Cookie就是在这样一个场景下诞生。 什么是Cookie Cookie具体指的是一段小信息，它是服务器发送出来存储在浏览器上的一组组键值对，下次访问服务器时浏览器会自动携带这些键值对，以便服务器提取有用信息。 Cookie的原理 cookie的工作原理是：由服务器产生内容，浏览器收到请求后保存在本地；当浏览器再次访问时，浏览器会自动带上Cookie，这样服务器就能通过Cookie的内容来判断这个是“谁”了。 查看 Cookie 我们使用Chrome浏览器，打开开发者工具。 Django中操作Cookie 　　获取Cookie request.COOKIES['key'] request.get_signed_cookie('key', default=RAISE_ERROR, salt='', max_age=None) get_signed

出于寻找Docker对Python相关项目部署的学习，找到腾讯课堂NEXT公开课中【Docker构建Python Web环境】的课程，本文对其进行内容梳理及知识点汇总。 该课程总计6小时左右，是个适合小白入门Docker部署的基础课程。课程主要章节内容如下： 系统及软件配置： Win10 + CentOS7 + Python3 + MySQL8 + PyCharm + VMware15 pro + MobaXterm + Navicat Premium 12 一、基础篇 1、CentOS默认安装了Python2，可以再安装Python3，原有Python2不做卸载，CentOS7存在对Python2程序依赖。 2、yum命令不能直接安装Python，需先安装epel源 yum install epel-release 3、Linux各文件夹含义 1 /boot 该目录默认下存放的是Linux的启动文件和内核。 2 /bin 该目录中存放Linux的常用命令。 3 /sbin 该目录用来存放系统管理员使用的管理程序。 4 /var 该目录存放那些经常被修改的文件，包括各种日志、数据文件。 5 /etc 该目录存放系统管理时要用到的各种配置文件和子目录，例如网络配置文件、Mysql配置文件。 6 /dev 该目录包含了Linux系统中使用的所有外部设备，它实际上是访问这些外部设备的端口

转载：https://blog.kuangstudy.com/index.php/archives/492/ 一.CRUD操作 1.基本操作流程 在Mapper接口中添加一个方法 在Mapper.xml中添加一个xml语句与方法对应 在测试类中添加一个方法测试 2.namespace 配置文件中namespace中的名称为对应Mapper接口或者Dao接口的完整包名,必须一致！ 3.select （1）介绍 select标签是mybatis中最常用的标签之一 select语句有很多属性可以详细配置每一条SQL语句 id：对应namespace中的方法名 parameterType：传入SQL语句的参数类型 。【万能的Map，可以多尝试使用】 resultType：SQL语句返回值类型。【完整的类名或者别名】 （2）案例：根据id查询用户 Mapper接口中添加方法 1 //根据ID查询用户 2 User getUserById(int id); Mapper.xml中添加xml语句 1 <!--根据ID查询用户--> 2 <select id="getUserById" parameterType="int" resultType="edu.ustc.wzh.pojo.User"> 3 select * from mybatis.user where id=#{id} 4 <

Session机制详解 虽然session机制在web应用程序中被采用已经很长时间了，但是仍然有很多人不清楚session机制的本质，以至不能正确的应用这一技术。本文将详细讨论session的工作机制并且对在Java web application中应用session机制时常见的问题作出解答。 一、术语session 在我的经验里，session这个词被滥用的程度大概仅次于transaction，更加有趣的是transaction与session在某些语境下的含义是相同的。 session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。有时候我们可以看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从 一个浏览器窗口打开到关闭这个期间 ①。最混乱的是“用户（客户端）在一次会话期间”这样一句话，它可能指用户的一系列动作（一般情况下是同某个具体目的相关的一系列动作，比如从登录到选购商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候 也可能仅仅是指一次连接 ，也有可能是指含义①，其中的差别只能靠上下文来推断②。 然而当session一词与网络协议相关联时，它又往往隐含了“ 面向连接”和/或“保持状态”这样两个含义 ，

什么是JWT 　　Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（ (RFC 7519 ).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。 Token认证和Session认证的区别　 　　传统的session认证 　　　　我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。 但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来. 　

############### python基础回顾：装饰器 ################ # 装饰器非常重要，1是写代码的时候，2是面试的时候，没有python开发不问装饰器的， # 装饰器绕不过去，一定会用到，不会装饰器不要说会python， # 理解Python装饰器(Decorator) # 想要理解Python中的装饰器，不得不先理解闭包（closure）这一概念。 # 闭包： # 就是一个函数里面又套上另一个函数的定义，你反而要用的是内部函数，而且内部函数会用到外部函数的变量，这种方式我们就成为闭包， # 我们把外部函数的变量和内部函数这个整体，我们称之为闭包， # 开放封闭原则： # 写代码需要遵循开放封闭原则，简单来说就是，他规定已经实现的代码功能不允许被修改，但是可以被扩展， # 封闭：已实现的功能 # 开放：对封闭的代码进行拓展开发， # 为什么已经实现的代码不允许被修改？因为这个代码可能很多地方都用到了，你改动了会影响一大片， # 所以使用装饰器，在不影响原有代码的基础上，动态的给函数加功能，但是要么在函数之前做事情，要么在函数之后做事情，不能在函数之中做事情 # 装饰器的应用： # 可以用来计算程序执行的时间 # 可以用来做加验证， 下面使用装饰器的思想来实现登陆的校验功能： ############### django-cookie的操作 ######