cookie

SSO（ Single Sign On ），即单点登录，是一种控制多个相关但彼此独立的系统的访问权限, 拥有这一权限的用户可以使用单一的ID和密码访问某个或多个系统从而避免使用不同的用户名或密码，或者通过某种配置无缝地登录每个系统 。 对于大型系统来说使用单点登录可以减少用户很多的麻烦。就拿百度来说吧，百度下面有很多的子系统——百度经验、百度知道、百度文库等等，如果我们使用这些系统的时候，每一个系统都需要我们输入用户名和密码登录一次的话，我相信用户体验肯定会直线下降。 与 SSO 交互的2个元素：1. 用户，2. 系统，它的特点是： 一次登录，全部访问 。SSO 是访问控制的一种，控制用户能否登录，即验证用户身份，而且是所有其它系统的身份验证都在它这里进行，从整个系统层面来看 SSO ，它的核心就是这3个元素了：1. 用户，2. 系统，3. 验证中心。 1、同一个域但不同的子域如何进行单点登录 假如我们的站点是按照下面的域名进行部署的： sub1.onmpw.com sub2.onmpw.com 这两个站点共享同一域 onmpw.com 。 默认情况下，浏览器会发送 cookie 所属的域对应的主机。也就是说，来自于 sub1.onmpw.com 的 cookie 默认所属的域是 .sub1.onmpw.com 。因此， sub2.onmpw.com 不会得到任何的属于 sub1

这个文章我们来讨论一下单点登录SSO的一些实现方式，其中包括对session和cookie的一些讨论。 一、 我们知道http协议是无状态的协议，也就是说一次请求对应一次响应，不和这次请求的上一次和下一次请求产生关联。那么这样就有一个问题，比如说，我们想实现一个购物车，我们往购物车中添加商品，每次刷新发现上一次添加的商品不见了，每次购物车里都是这次添加的商品，前面添加的不见了。为什么？就是因为http是无状态协议，它压根不知道你上一次往购物车里添加了什么商品。那么我们要怎么做才能让购物车保存我们前面添加的商品？那么，我们首先要让服务器知道”你就是你“。 举个例子，比如说现在有两个人user1，user2在往购物车里添加东西。user1添加了A，B商品，user2添加了C，D商品，此时user1想看看自己到底往购物车里放了什么商品，于是user1点了一下购物车的图标，服务器收到请求，有个用户要查看购物车的商品，要把购物车的商品返回给用户。那么到底是返回user1的还是user2的呢？也就是说服务器凭什么知道这次请求来自user1（把user1的购物商品返回）呢？ 那么是不是说我们让我们的浏览器和服务器之间通过一个凭证来通信就可以解决。还是那上面的例子来说。比如user1登录了这个购物网站，服务器收到了这个请求，然后告诉user1说我给你一个凭证（card1）

什么是单点登录(SSO) 单点登录主要用于多系统集成，即在多个系统中，用户只需要到一个中央服务器登录一次即可访问这些系统中的任何一个，无须多次登录。 单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 web系统如何实现单点登录 目前已经有了成熟的单点登录实现方案，比如CAS，我们只要在web系统中应用单点登录方案CAS即可。(主要涉及到注册登录验证等模块的改动) 什么是CAS CAS (Central Authentication Service) 是耶鲁 Yale 大学发起的一个java开源项目，旨在为 Web应用系统提供一种可靠的 单点登录 解决方案（ Web SSO ）， CAS 具有以下特点： 1、 开源的企业级单点登录解决方案； 2、 CAS Server 为需要独立部署的 Web 应用----一个独立的Web应用程序(cas.war)。 ； 3、 CAS Client 支持非常多的客户端 ( 指单点登录系统中的各个 Web 应用 ) ，包括 Java, .Net, PHP, Perl, 等。 CAS在2004年12月成为Jasig项目，所以也叫JA-SIG CAS。 官网1: https://apereo.github.io/cas

单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。实现单点登录说到底就是要解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性，因此要点也就以下几个： 存储信任 验证信任 只要解决了以上的问题，达到了开头讲得效果就可以说是SSO。最简单实现SSO的方法就是用Cookie，实现流程如下所示： 不然发现以上的方案是把信任存储在客户端的Cookie里，这种方法虽然实现方便但立马会让人质疑两个问题： Cookie不安全 不能跨域免登 对于第一个问题一般都是通过加密Cookie来处理，第二个问题是硬伤，其实这种方案的思路的就是要把这个信任关系存储在客户端，要实现这个也不一定只能用Cookie，用flash也能解决，flash的Shared Object API就提供了存储能力。 一般说来，大型系统会采取在服务端存储信任关系的做法，实现流程如下所示： 以上方案就是要把信任关系存储在单独的SSO系统（暂且这么称呼它）里

单点登录SSO 一.单点登录SSO(只提供思路,不提供实现) 什么是单点登录？单点登录全称Single Sign On（以下简称SSO），是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分(类似在新浪微博与新浪博客那样子) 二. 思路 (以java web来讲解) 1.相比于单系统登录，sso需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，sso认证中心验证用户的用户名密码没问题，创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。 2.在web中怎么实现,也就是说在浏览器中怎么知道用户使用的多个系统是否是你的多个系统且是否登录了呢 ———————————————-cookie 3.使用cookie 来验证用户是否登录有3种情况, (1.)所有子系统与认证中心系统同域 (类似 www.a.com/sso1 www.a.com/case1 www.a.com/case2 ) (2.)所有子系统与认证中心系统同父域 (类似 case.a.com/sso1 case1.a.com/case1 case2.a.com/case2 )

原文地址： http://www.blogjava.net/persister/archive/2009/10/02/297103.html 调用Cookie对象的构造函数可以创建Cookie。Cookie对象的构造函数有两个字符串参数：Cookie名字和Cookie值。 Cookie cookie = new Cookie(name,value); 调用下面的方法时出现一个问题 response.addCookie(cookie)；//cookie 是一个Cookie实例 问题报错：java.lang.IllegalArgumentException: Control character in cookie value, consider BASE64 encoding your value 很显然Cookie之中存在了非法参数，经过测试发现cookie之中包含""r"n"、""n"时就会出现这个异常。 因为cookie中部分值是通过文本框录入的，在<textarea/>标签中键入回车键后，value值中就加入了""r"n"， 把这样的值赋给cookie，执行response.addCookie(cookie)；时则出现异常。 解决办法：使用String类的replace（）方法。 Java代码 1 str = str.replace(""r"n", " < br > "); 2

INFO:sql注入我想很多人都接触过，大多数都是接触得get 和post注入的形式，你或是用手工，或是用工具，cookie注入也是一样，今天就给大家讲一讲cookie如何注入,考虑到大家的实际情况，这里就不通过手工来进行，我们就借助一些工具来完成。（大牛看到请不要打我~~） 小知识：所谓SQL注入，就是通过把SQL命令插入到Web 表单 提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。 比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到 SQL注入式攻击 ，当然现在的网站已经很少有sql注入（get,post,cookie）了,但是有些网站还是存在这样的问题，比如说经常用别人模板的人，有些模板下面的文件目录下包含了当前网站的一些信息，你不及时发现就会给攻击者可乘之机，php网站的建设者一定要注意模板使用方面的问题。 百度百科:Cookie是由 服务器端 生成，发送给User-Agent（一般是浏览器），浏览器会将Cookie的key/value保存到某个目录下的 文本文件 内

1. PHP 的COOKIE cookie 是一种在远程浏览器端储存数据并以此来跟踪和识别用户的机制。 PHP 在http 协议的头信息里发送cookie，因此 setcookie() 函数必须在其它信息被输出到浏览器 前调用，这和对 header() 函数的限制类似。 1.1 设置cookie: 可以用 setcookie()或 setrawcookie()函数来设置 cookie。也可以通过向客户端直接发送http 头来 设置。 1.1.1 使用 setcookie()函数设置cookie: bool setcookie ( string name [, string value [, int expire [, string path [, string domain [, bool secure [, bool httponly]]]]]] ) name: cookie 变量名 value: cookie 变量的值 expire: 有效期结束的时间 path: 有效目录 domain: 有效域名，顶级域唯一 secure: 如果值为 1，则cookie 只能在https 连接上有效，如果为默认值 0，则http 和 https 都可 以。 例子： 代码片段 <?php $value = 'something from somewhere'; setcookie(

前言 一个http请求中，我们经常会涉及到Get请求的URL Param，POST请求的HTTP Body，Response Json，这些都是一个标准REST API标配的元素。 在一些安全验证的API中，通常会涉及到Cookie。当用户成功登陆后，服务器会在Response Header中写入一个Set-Cookie字段，用来标识用户已经登陆（授权）成功，客户端浏览器接收后会把这个Cookie字段保存在客户端本地。当客户端再次请求API时，就会在Request Header中带上这个Cookie值，告诉服务器：嗨，我已经授权过咯，我的cookie值是xxx，我现在要读取一些信息，请放行～ IOS中的网络请求 一个完整的网络请求，需要先确定Request URL，带上参数，然后发送Request，然后接收Response，处理Response Data。 在IOS中，分别对应如下： //Request URL NSURL //一个完整的Request对象 NSURLRequest //发送请求连接的主要操作者 NSURLConnection //包含返回数据的Response NSURLResponse 下面是一个简单的GET请求代码： let request = NSURLRequest(URL: NSURL(string: "http://devonios.com")!)

jQuery-cookie插件的使用 什么是插件？ 基于jQuery的语法，按照一定规范书写，具有特定功能的脚本文件，称为插件。 插件除了js文件之外，有的还包含css文件，图片和字体等资源文件。 在jQuery的官网 https://jquery.com/ 搜索和下载需要的插件。 1.引入cookie插件 <head> <meta charset="utf-8"> <title>cookie插件的使用</title> <!-- 首先引入jQuery --> <script src="js/jquery-1.11.3.js" type="text/javascript" charset="utf-8"></script> <!-- 插件基于jQuery，然后再引入下载的cookie插件 --> <script src="../js/cookie/jquery.cookie.js" type="text/javascript" charset="utf-8"></script> </head> cookie是什么？ cookie就是浏览器存储在用户电脑上的一小段文本文件。一个web页面或服务器会告知浏览器按照一定规范来存储这些信息，并在之后的请求中将这些信息发送至服务器。web服务器就可以使用这些信息来识别不同的用户。例如，访问一个网站输入账号密码