互联网上的单点登录研究

随着互联网络应用的普及,越来越多的人开始使用互联网上提供的服务。然而目前提供服务的网站大多采用用户名、口令的方式来识别用户身份,这使得用户需要经常性的输入自己的用户名、口令。显然这种认证方式存在着弊端:随着用户网络身份的增多,用户相应的需要记忆多组用户名、口令,这给用户造成记忆上的负担;另外频繁的输入用户名、口令,会相应的增大用户的口令密码被破解的机率。为了改变这一现状,单点登录技术应运而生。单点登录技术的核心思想是通过一定的方式使得各提供服务的网站之间建立某种联系,用户只需要在其中一个认证网站进行登录后,即可实现全局登录,当用户再访问其他网站时,不需要再次登录,其身份就可以被验证。我们可以看到采用单点登录技术后,用户只需要记忆一组用户名、口令,并且在登录多个网站时只需要输入一次用户名、口令,这就使得用户可以更加安全快捷的使用互联网上的各种服务。

单点登录的一般模型

在单点登录的一般模型中,一般由三部分构成:(1)用户 (2)身份提供者 (3)服务提供者。如图1所示。

用户是指通过浏览器来使用单点登录服务的个体。身份提供者在单点登录中提供对个体的身份验证服务,相当于一个权威机构。服务提供者是指具体为用户提供某种服务的机构。用户在身份提供者那里注册身份,当用户进行单点登录时,需要在身份提供者处登录,进行身份验证,由身份提供者为用户标记登录信息。通常把用户在身份提供者处进行的登录称作全局登录。用户在全局登录后,当访问其它的服务提供者时,被访问的服务提供者首先直接与身份提供者进行交互,来询问该用户是否已全局登录,如果确定该用户已全局登录,则允许该用户来访问自己提供的服务,否则将该用户重定向到身份提供者处,进行全局登录。

在具体的单点登录实现中,身份提供者和服务提供者进行交互的方式不尽相同。如微软的Passport单点登录采用的是在重定向信息中包含加密后的验证信息来进行交互,而自由联盟的单点登录规范是采用安全声明标记语言(SAML)来进行交互的。下面本文就通过介绍当前这两个主流的单点登录协议:微软Passport单点登录协议和自由联盟规范来进一步阐述单点登录技术。

一、微软Passport单点登录协议

1.1 微软Passport服务

提及微软Passport单点登录协议,我们自然要先介绍的是微软Passport服务。在微软的www.passport.com站点上我们可以看到微软Passport的使用条款和通告。微软Passport 是由微软公司运行的一种Web 服务,该服务会使用户登录到网站以及执行电子商务交易的过程变得更加简便。微软的Passport服务是.Net战略的一部分,通过一次登录就可以使用户获得访问很多网站的权限。微软宣称Passport的目的是使会员在使用互联网和在线购物时更方便、快捷和安全,它得到了包括1-800-Flowers、CostCo、OfficeMax和Victoria Secret在内的诸多著名在线商店的支持。微软Passport服务从本质上来说是一种由微软控制的中央统筹式的单一登录服务。微软旗下的Hotmail、Messenger与ISP服务(MSN)都有加入此机制,目前约有2亿个使用账户。

1.2 微软Passport单点登录协议

在微软Passport服务模式中,有三个主体:(1)使用web浏览器的用户(假设该用户已经注册了Passport服务),(2)服务提供者(对用户提供某种服务的网站),(3)Passport登录服务器。Passport登录服务器保存着用户的认证信息以及用户的个人信息,服务提供者在得到用户允许的前提下可以到Passport登录服务器上获取用户个人信息。

微软Passport单点登录协议流程如下[1]:当一个用户通过浏览器访问一个服务提供者网站时,如果该网站需要验证用户的身份,就把该用户的浏览器重定向到Passport登录服务器。下一步Passport登录服务器通过SSL连接为用户提供一个登录页面,在用户登入该服务器后,被重定向回服务提供者网站。此时认证信息被包含在重定向消息中。该认证信息使用三重DES加密算法加密,加密密钥是由Passport登录服务器和服务提供者网站事先协商好的。在服务提供者网站检验了认证信息的真实性后,即可认为该用户成功登录。具体流程图可参考图2所示。

微软Passport单点登录协议采用了Kerberos认证机制来完成身份认证工作。Kerberos是一种为网络通信提供可信第三方服务的面向开放系统的认证机制。在Kerberos认证机制中,每当用户(client)申请得到某服务程序(server)的服务时,用户和服务程序会首先向Kerberos要求认证对方的身份,认证建立在用户(client)和服务程序(server)对Kerberos的信任的基础上。在申请认证时,client和server都可看成是Kerberos认证服务的用户,为了和其它服务的用户区别,Kerberos用户统称为principle,principle既可以是用户也可以是某项服务。当用户登录到工作站时,Kerberos对用户进行初始认证,通过认证的用户可以在整个登录时间得到相应的服务。Kerberos既不依赖用户登录的终端,也不依赖用户所请求的服务的安全机制,它本身提供了认证服务器来完成用户的认证工作[7]。简单地说,Kerberos通过集中存储的安全信息和分布式的“tickets”来实现用户身份认证。具体而言,微软Passport服务通过如下步骤实现用户身份验证:

用户开启客户端应用程序或浏览器,打开登录界面,并输入用户名、口令。 登录动作引发客户端应用程序或网站向微软Passport请求一个登录确认证明(即“ticket-granting-ticket”,TGT)。 微软Passport验证用户用户名、口令,颁发TGT,确认登录已经成功。在满足一定安全约束条款的前提下,该TGT在一定时期内被缓存。 客户端应用程序或网站向微软Passport提交TGT,同时请求颁发一个“会话证明”。 微软Passport使用TGT来验证客户端的身份是否有效,确认后向相应的Web Service颁发“会话证明”。 客户端向所请求的Web Service提交会话证明,经确认后,客户端开始同Web Service进行信息交换,所有数据都经由该“会话证明”加密从而确保安全。

1.3 微软Passport小结

虽然微软Passport已经提供了多年的服务,但是其安全性一直为人们所置疑。首先,其中央统筹的模式是最为大众所质疑的。因为核心的验证服务器以及用户个人信息服务器都是微软一手控制的,再加上其技术细节并不对外公开,而且没有依据某一标准,致使人们一直担忧用户的个人资料被泄漏。其次,微软的Passport系统曾被个人或黑客多次入侵。这些都限制了微软Passport服务的进一步推广。

二、自由联盟规范

4.1 自由联盟(Liberty Alliance)

自由联盟是一个联盟机构的名称,该联盟的宗旨是创建一个经由与Internet相连的任何器件都能实现的具有开放性的、联合的、单一签字身份识别的解决方案,该机构的目标是为实现利用因特网进行交易时随时随地的单点登录认证,并且进行有关标准的制订。所有商业机构和非商业机构都可取得该机构的成员身份。加盟该机构的创始企业中有服务提供、汽车制造、金融服务、旅行业、数字媒体、零售业、电信及技术相关业界的著名企业。目前自由联盟由170多家厂商组合,包括Sun、Nokia、American Express等,他们负责提供技术规范与商业指南来当作跨企业的身份认证服务。Liberty本身并不产生应用,这方面是由技术厂商(如Sun、Novell、Peoplesoft与HP等)来开发支持Liberty标准的兼容应用。自由联盟规范可让不同的服务供应商加入一个联邦式的信赖网络中[6]。

自由联盟的主要目标有如下三个方面:

使个人消费者和企业用户能够安全保管个人信息。基此,推进无信息垄断的、可以相互运用并跨越多个网络的服务。 制订实现“单点登录”的开放标准。基此,使用户在任何1个WWW站点通过认证后,不必接受其它站点认证就可以使用其服务。 制订所有接入因特网的设备都可以使用的网络认证开放标准。基此使手机、车载设备和信用卡等各种各样的终端间都能进行安全的认证。

4.2 自由联盟规范 自由联盟于美国当地时间2003年3月11日公布了单点登录架构“Liberty Alliance Federated Network Identity Architecture”的概要及其发展蓝图。自由联盟声称利用该架构能够解决众多阻碍Web认证服务的技术性障碍。

自由联盟分两个阶段公布支持该架构的规范――自由联盟规范。在第一阶段,自由联盟于2002年7月公布了作为联盟用户管理基础的规格集“Liberty Alliance Identity Federation […]

单点登录学习笔记

单点登录SSO(Single Sign-On)是身份管理中的一部分。SSO的一种较为通俗的定义是:SSO是指访问同一服务器不同应用中的受保护资源的同一用户,只需要登录一次,即通过一个应用中的安全验证后,再访问其他应用中的受保护资源时,不再需要重新登录验证。

单点登陆的模式

DNN模式。也就是把各个子系统的界面都集成到一起,当到一个类似DNN一样UI的容器管理器里面,用这样的方式,来实现一次登陆,然后在各个其他系统中继续享有这个用户登录服务。 其实这是采用一个WebApplication的方式。

类似微软的passport,一次登陆之后,就可以在msn,hotmail,或者space中任其切换而不需要重新登陆。这一中模式就不是一个WebApplication了,而是在多个Application上的控制。

单点登录(SSO)的实现原理

登陆点。理想的情况是用户通过任何应用系统都能进行登陆,而且效果一样。这种单一的登陆点在整个系统的设计中是唯一认证用户的地方,由登陆点将相应的用户信息传递给应用系统,应用系统利用这些信息来进行用户的验证。 应用系统的单点登录(SSO)集成。并不是任何系统都能够使用SSO,只有那些符合SSO规范,使用SSO API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统,屏蔽已有的应用系统的用户认证模块,使用系统提供的SSO API来验证用户,以及对用户的操作进行授权。 统一的认证,权限信息库。通常SSO要求有统一的认证,权限存放库。但现实中,有的系统无法使用外部的认证,授权信息库,所以就需要在应用系统和SSO认证系统之间进行认证,同时进行授权信息的数据同步。 实现描述:在用户成功通过SSO认证系统认证之后,系统提供的映射授予权限来为用户登录到其有权可以使用的应用系统。系统提供的映射取消用户权限来实现用户的注销功能。

要实现SSO需要以下主要的功能

所有应用系统共享一个身份认证系统; 所有应用系统能够识别和提取ticket信息; 应用系统能够识别已经登录过的用户,能自动判断当前用户是否登录过,从而完成单点登录的功能。 其中,统一的身份认证系统最重要,认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户。另外,认证系统还应该对ticket进行效验,判断其有效性。整个系统可以存在两个以上的认证服务器,这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议,互相交换认证信息,就能完成更高级别的单点登录。

使用SSO的好处主要有

方便用户 用户使用应用系统时,能够一次登录,多次使用。用户不再需要每次输入用户名称和用户密码,也不需要牢记多套用户名称和用户密码。单点登录平台能够改善用户使用应用系统的体验。 方便管理员 系统管理员只需要维护一套统一的用户账号,方便、简单。相比之下,系统管理员以前需要管理很多套的用户账号。每一个应用系统就有一套用户账号,不仅给管理上带来不方便,而且,也容易出现管理漏洞。 简化应用系统开发 开发新的应用系统时,可以直接使用单点登录平台的用户认证服务,简化开发流程。单点登录平台通过提供统一的认证平台,实现单点登录。因此,应用系统并不需要开发用户认证程序。

实现SSO的技术主要有

基于cookies实现,需要注意如下几点:如果是基于两个域名之间传递sessionid的方法可能在windows中成立,在 unix&linux中可能会出现问题;可以基于数据库实现;在安全性方面可能会作更多的考虑。另外,关于跨域问题,虽然cookies本身不跨域,但可以利用它实现跨域的SSO。 Broker-based(基于经纪人),例如Kerberos等;这种技术的特点就是,有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价,并为认证提供一个公共和独立的”第三方”。例如Kerberos、Sesame、IBM KryptoKnight(凭证库思想)等。 Agent-based(基于代理) 在这种解决方案中,有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如, 它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理被放在服务器上面,在服务器的认证系统和客户端认证方法之间充当一个”翻译”。例如 SSH等。 Token-based,例如SecurID、WebID、现在被广泛使用的口令认证,比如FTP,邮件服务器的登录认证,这是一种简单易用的方式,实现一个口令在多种应用当中使用。 基于网关 Agent and Broker-based。 基于安全断言标记语言(SAML)实现,SAML(Security Assertion Markup Language,安全断言标记语言)的出现大大简化了SSO,并被OASIS批准为SSO的执行标准。开源组织OpenSAML 实现了 SAML 规范,可参考 http//www.opensaml.org。

Related posts:

PPC竞价管理系统设计初探 我的wordpress所使用的robots.txt 当当网:从搜索到发现

[…]

OAuth和OpenID的区别

前面两篇文章(OAuth学习笔记和OpenID学习笔记)都说了可以用来认证身份,但是他们之间到底有哪些不同,哪些情况应该用OAuth,哪些情况应该用OpenID呢?下面就一起来看下他们之间的区别。

简短的说,OAuth关注的是authorization;而OpenID侧重的是authentication。从表面上看,这两个英文单词很容易混淆,但实际上,它们的含义有本质的区别:

authorization: n. 授权,认可;批准,委任 authentication: n. 证明;鉴定;证实

OAuth关注的是授权,即:“用户能做什么”;而OpenID关注的是证明,即:“用户是谁”。下面就分别来说两者的功能。

OpenID

用户希望访问其在example.com的账户 example.com (在OpenID的黑话里面被称为“Relying Party”) 提示用户输入他/她/它的OpenID 用户给出了他的OpenID,比如说”http://user.myopenid.com” example.com 跳转到了用户的OpenID提供商“mypopenid.com” 用户在”myopenid.com”(OpenID provider)提示的界面上输入用户名密码登录 “myopenid.com” (OpenID provider) 问用户是否要登录到example.com 用户同意后,”myopenid.com” (OpenID provider) 跳转回example.com example.com 允许用户访问其帐号

OAuth

用户在使用example.com时希望从mycontacts.com导入他的联系人 example.com (在OAuth的黑话里面叫“Consumer”)把用户送往mycontacts.com (黑话是“Service Provider”) 用户在mycontacts.com 登录(可能也可能不用了他的OpenID) mycontacts.com问用户是不是希望授权example.com访问他在mycontact.com的联系人 用户确定 mycontacts.com 把用户送回example.com example.com 从mycontacts.com拿到联系人 example.com 告诉用户导入成功

OpenID是用来验证的,就是说可以用一个url来唯一表明身份(不用挨个记每个网站的用户密码)。OAuth是用来授权的(俺可以授权一个网站访问俺在另外一个网站的数据,而俺不用把俺的密码给第一个网站。

很多人现在错误的把OAuth当做OpenID使用。但是其实也不会照成什么影响。如水煮鱼开发的WordPress插件:

WordPress的评论只要求身份认证即可,无需权限认证。

Related posts:

OpenID学习笔记 市场营销中的4P […]

OpenID学习笔记

一、OpenID简介

OpenId是一个以用户为中心的数字身份识别框架,它具有开放、分散、自由等特性。OpenId的创建是基于这样一个概念:我们可以通过URI(或者URL网址)来识别一个网站。同样,我们也可以通过这样的方式来识别一个用户的身份。OpenId系统的身份认证就是通过URI来认证用户身份。目前绝大部分网站都是通过用户名与密码来登录认证用户身份,这就要求大家在每个你要使用的网站上注册一个帐号。如果使用OpenId,你可以在一个提供OpenId的网站上注册一个OpenId,以后你可以使用这个OpenId去登录支持OpenId的网站。这正是一处注册,到处使用的体现。

登录一个支持 OpenID 的网站非常简单(即便你是第一次访问这个网站也是一样)。只需要输入你注册好的 OpenID 用户名,然后你登录的网站会跳转到你的 OpenID 服务网站,在你的 OpenID 服务网站输入密码(或者其它需要填写的信息)验证通过后,你会回到登录的网站并且已经成功登录。 OpenID 系统可以应用于所有需要身份验证的地方,既可以应用于单点登录系统,也可以用于共享敏感数据时的身份认证。

除了一处注册到处通行以外,OpenID 给所有支持 OpenID 的网站带来了价值--共享用户资源。用户可以清楚的控制哪些信息可以被共享,例如姓名、地址、电话号码等。今天,OpenID 作为以用户为中心的身份验证系统已经为数百万的用户提供了服务。

二、OpenID相关术语

End User:终端用户,使用OP与RP的服务 Relying Party依赖方:简称RP,服务提供者,需要OP鉴权终端用户的身份 OpenID Provider:OpenID提供者,简称OP,对用户身份鉴权 Identifier标识符:标识符可以是一个HTTP、HTTPS或者XRI(可扩展的资源标识) User-Agent:实现了HTTP1.1协议的用户浏览器 OP Endpoint URL:OP鉴权的URL,提供给RP使用 OP Identifier:OP提供给终端用户的一个URI或者XRI,RP根据OP Identifier来解析出OP Endpoint URL与OP Version User-Supplied Identifier:终端用户使用的ID,可能是OP提供的OpenID,也可以是在RP注册的ID。RP可以根据User-Supplied Identifier来解析出OP Endpoint URL、OP Version与OP_Local Identifer Claimed Identifier:终端用户声明自己身份的一个标志,可以是一个URI或者XRI OP-Local Identifier:OP提供的局部ID

三、OpenID验证流程

[…]

矿工生涯——Programmers(28)

载于《程序员》杂志2011年第8期。

从第27期起,开始在杂志上登出整P的大幅漫画,需要看大图的同学们,迅猛点击下图。

这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主。

如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件。arthur369@gmail.com。

Cookie与Session的区别

cookie机制

Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie规范。网络服务器用HTTP头向客户端发送cookies,在客户终端,浏览器解析这些cookies并将它们保存为一个本地文件,它会自动将同一服务器的任何请求缚上这些cookies 。

具体来说cookie机制采用的是在客户端保持状态的方案。它是在用户端的会话状态的存贮机制,他需要用户打开客户端的cookie支持。cookie的作用就是为了解决HTTP协议无状态的缺陷所作的努力。

正统的cookie分发是通过扩展HTTP协议来实现的,服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie,如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置,则把该cookie附在请求资源的HTTP请求头上发送给服务器。

cookie的内容主要包括:名字,值,过期时间,路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间,则表示这个cookie的生命期为浏览器会话期间,关闭浏览器窗口,cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里,当然这种行为并不是规范规定的。若设置了过期时间,浏览器就会把cookie保存到硬盘上,关闭后再次打开浏览器,这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享,比如两个IE窗口。而对于保存在内存里的cookie,不同的浏览器有不同的处理方式。

而session机制采用的是一种在服务器端保持状态的解决方案。同时我们也看到,由于采用服务器端保持状态的方案在客户端也需要保存一个标识,所以session机制可能需要借助于cookie机制来达到保存标识的目的。而session提供了方便管理全局变量的方式 。

session是针对每一个用户的,变量的值保存在服务器上,用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器,当客户禁用cookie时,这个值也可能设置为由get来返回给服务器。

就安全性来说:当你访问一个使用session 的站点,同时在自己机子上建立一个cookie,建议在服务器端的session机制更安全些,因为它不会任意读取客户存储的信息。

session机制

session机制是一种服务器端的机制,服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。

当程序需要为某个客户端的请求创建一个session时,服务器首先检查这个客户端的请求里是否已包含了一个session标识(称为session id),如果已包含则说明以前已经为此客户端创建过session,服务器就按照session id把这个session检索出来使用(检索不到,会新建一个),如果客户端请求不包含session id,则为此客户端创建一个session并且生成一个与此session相关联的session id,session id的值应该是一个既不会重复,又不容易被找到规律以仿造的字符串,这个session id将被在本次响应中返回给客户端保存。

保存这个session id的方式可以采用cookie,这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止,则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。

经常被使用的一种技术叫做URL重写,就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单,添加一个隐藏字段,以便在表单提交时能够把session id传递回服务器。

Cookie与Session都能够进行会话跟踪,但是完成的原理不太一样。普通状况下二者均能够满足需求,但有时分不能够运用Cookie,有时分不能够运用Session。下面经过比拟阐明二者的特性以及适用的场所。

1 .存取方式的不同

Cookie中只能保管ASCII字符串,假如需求存取Unicode字符或者二进制数据,需求先进行编码。Cookie中也不能直接存取Java对象。若要存储略微复杂的信息,运用Cookie是比拟艰难的。

而Session中能够存取任何类型的数据,包括而不限于String、Integer、List、Map等。Session中也能够直接保管Java Bean乃至任何Java类,对象等,运用起来十分便当。能够把Session看做是一个Java容器类。

2 .隐私策略的不同

Cookie存储在客户端阅读器中,对客户端是可见的,客户端的一些程序可能会窥探、复制以至修正Cookie中的内容。而Session存储在服务器上,对客户端是透明的,不存在敏感信息泄露的风险。

[…]

使用 PHP导出Google Analytics数据。

上篇文章介绍了一个Excel导出Google Analytics 数据,这一篇算是进阶,教你怎么使用PHP 导出Google Analytics数据。

关于Google Analytics接口的介绍请看这里:Google Analytic 数据导出API接口

GAPI 即 Google Analytics PHP5 Interface的主要功能有:

自动选择连接方式是curl或fopen 支持GA维度指标数据 账户数据映射-获得参数的方法 报告数据映射-获得维度和指标的方法 容易使用的过滤器 面向对象的代码可以让你在其他系统中使用。

GAPI使用示例:

<?php define(‘ga_email’,’username@gmail.com’); define(‘ga_password’,’password’); define(‘ga_profile_id_cn_0′,’1234567’); require ‘gapi.class.php’;   $start = mktime(0,0,0,date("m"),date("d")-30,date("Y")); $end = mktime(0,0,0,date("m"),date("d")-2,date("Y")); $start_date = date("Y-m-d",$start); $end_date = date("Y-m-d",$end); $ga = new gapi(ga_email,ga_password,isset($_SESSION[‘ga_auth_token’])?$_SESSION[‘ga_auth_token’]:null); $_SESSION[‘ga_auth_token’] = $ga->getAuthToken(); ?>   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML […]

网站统计:第一方Cookie和第三方Cookie

什么是 Cookie?

Cookie 是您访问过的网站创建的文件,用于存储浏览信息,例如您的网站偏好设置或个人资料信息。共有两种类型的 Cookie:第一方 Cookie 是由地址栏中列出的网站域设置的 Cookie,而第三方 Cookie 来自在网页上嵌入广告或图片等项的其他域来源。

Cookie可以用来提升用户体验,比如网站可以使用Cookie来记录用户的登录状态,用户只要登录一次就可以不用登录了,购物网站通过Cookie来保存购物车中的商品等。同时很多的网站分析都是依靠Cookie来完成的。

以网站统计为例,目前主要的统计方式是日志记录法和页面标记法。一般日志记录法细化到IP,而页面标记法细化到Unique  Visitor。UV并不仅仅是一个指标,更重要的是的它可以把一个用户多次访问的事件联系在一起。包括用户第一次从哪里来,第二次从哪里来,在网站上的浏览轨迹等都可以查询出来。

Cookie是如何工作的?

一般来说,Cookie通过HTTP Headers从服务器端返回到浏览器上。首先,服务器端在响应中利用Set-Cookie header来创建一个Cookie ,然后,浏览器在它的请求中通过Cookie header包含这个已经创建的Cookie,并且反它返回至服务器,从而完成浏览器的论证。

比如,我们访问一个网站,来到了登录的页面。页面需要我们输入用户名和密码,同时下面有一个选项,叫“保留我的登录状态”,如果输入了用户名,密码。为了下次在来这个网站,不用再重新输入,我们激活了保留状态的选项。最后点了提交。这时,我们的浏览器就会和网站服务器之间通过HTTP协议进行连接,提交刚才输入的内容和选择。服务器收到以后,会判断这个用户名密码是否正确,因为我们需要保留状态,就需要设置Cookie来记录状态。那服务器会在返回的HTTP数据包的头部包含SetCookie这个指令来告诉浏览器要保存的Cookie。浏览器收到以后会把这个Cookie加密存储到电脑上。这个Cookie记录的一般是用户在这个网站的唯一的ID。之后,只要每次访问这个网站(只要还是这个域名),我们的浏览器在请求这个网站服务器数据的时 候,都会在HTTP请求数据包的头部增加一条包含Cookie数据的信息,比如这里会告诉服务器:“我是你的用户,我的ID是9527。”那服务器收到这 个信息,就不会再提示登录,而我们就已经是登录的状态了。

第一方Cookie和第三方Cookie

Cookie通常可以分为两类,第一方Cookie和第三方Cookie,第一方Cookie和第三方Cookie,都是网站在客户端上存放的一小块数据。他们都由某个域存放,只能被这个域访问。他们的区别其实并不是技术 上的区别,而是使用方式上的区别。比如,访问www.a.com这个网站,这个网站设置了一个Cookie,这个Cookie也只能被www.a.com 这个域下的网页读取,这就是第一方Cookie。如果还是访问www.a.com这个网站,网页里有用到www.b.com网站的一张图片,浏览器在 www.b.com请求图片的时候,www.b.com设置了一个Cookie,那这个Cookie只能被www.b.com这个域访问,反而不能被 www.a.com这个域访问,因为对我们来说,我们实际是在访问www.a.com这个网站被设置了一个www.b.com这个域下的Cookie,所以叫第三方Cookie。

第一方Cookie的优势和应用

第一方Cookie的最大优势是接受率高。一般主流的浏览器的都会有隐私的设置,可以让用户设置是否接受Cookie,接受哪些Cookie。除了 完全不接受Cookie这个设置以外,其他情况下,第一方Cookie都是会被用户接受的(不接受的话,是没办法把那小块数据保存下来的)。所以,如果没有特殊要求,使用第一方Cookie会比第三方Cookie,我们通过分析工具得到的数据会更准确。

第三方Cookie的优势和应用

第三方Cookie的接受率不如第一方Cookie(不过主流的浏览器默认的设置下也接受带P3P协议的第三方Cookie,我的经验是接受率能达 到90%,甚至95%以上),但在某些特定情况下可以实现第一方Cookie无法实现的功能。比如,当我们有多个域名的网站需要跟踪,我们希望了解到用户点击某个广告到达域名A下的网页,然后可能浏览了不论那个域名下的页面,最后在域名B下的网页完成注册的情况。广告可以在域名A下的网页被跟踪到,而注册可以在域名B下的网页跟踪到。如果我们使用第一方Cookie,会为域名A建立一个Cookie,为域名B再建立一个Cookie,他们可以关联各自域名下网页上的行为,但是无法关联起来。而使用第三方Cookie,那么无论多少个域,都只有一个Cookie,一个属于第三方域的Cookie,网站下所有域都能共享这个Cookie,那么所有的行为都能被关联起来分析。

结论:对于通过脚本型的网站分析工具来获取数据

Cookie是必须的,离开Cookie我们什么也分析不了。 第一方Cookie接受率高,更准确,没有特殊需要就用他。 第三方Cookie可以跨域跟踪,特别需求可以应用。

P3P解决第三方cookie存取的问题

P3P(Platform for Privacy Preferences)是由万维网协会研制,它为Web用户提供了对自己公开信息的更多的控制。支持P3P的Web站点可以为浏览者声明他们的隐私策略。支持P3P的浏览器则可以将Web站点的策略与用户的隐私偏好进行对比,并为用户提出不匹配的警告。因此,用户可以被通知有关Web隐私的处理方式。更详细的说明请看http://www.w3.org/P3P/的介绍。

以上几乎都是废话,我自己的理解就是通过P3P 可以使 用户自己指定浏览器的隐私策略。而这里只用到了关于cookie的一些设置。 我们打开ie浏览器–>工具–>internet选项–>隐私分页 用户可以通过手工 “导入” 用户隐私策略文件

PHP使用P3P来跨域跟踪的示例

首先修改Windows文件,将要测试的两个域名进行指向。

127.0.0.1        www.a.com 127.0.0.1        […]

弱爆程序员的特征值

【感谢网友sumtec投递此文,很欢乐也有意思,与大家共勉】

首先说明:

1、以下特征是真实遇到过的,同事犯过的,乃至我自己也犯过的; 2、为了剧情需要,某些例子进行了一些夸张修饰等演绎创作,如无雷同,请勿生气; 3、如果你出现过以下症状之一,并不代表你就是弱爆了,但是如果你一直出现,乃至一说到这个大家就能联想到你,那么你就得小心了; 4、如果你是集这几个的大乘者,恭喜你,你已经找到了离开这个行业的充足理由了。

好了,搞定!

“那个Bug解决了吗?”

“好了,搞定!”

“这么快?”

正当你非常欣喜的时候,就传来了噩耗:刚才还能编译成功的,就失败了。(好吧,我们的集成编译尚未成功配置上,理论上这种事情应该会被退回。)又或者能编译成功,但是呢,原来明明能起作用的一个下拉框,突然发神经的不起作用了。最隐蔽的莫过于,一切正常,但是当你看到代码的时候,你就晕厥过去了。比如我们曾经发现了一个Bug,简单说就是每次用户点击某个东西,就会执行下面的这段C#代码:

controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

这个Bug很明显会导致速度越来越慢,因为同一个更新操作会被更新N次,并且这个N会越来越大。其实这个Bug已经够弱了,但是后来居然被修改为:

controlPropertyPanel.PropertyChanged -= this.UpdatePropertyOnChanged; controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

这段代码能编译,能执行,但是就是弱爆了。因为这不仅仅没有从根本上去掉造成问题的逻辑,还会带来更多的困惑:为什么要先减后加呢?

这类特征,请大家看看有趣的《各种流行的编程风格》,我这个例子算是一种撞大运。我觉这吧,这类问题都是因为只想解决一些表面的东西为目的,完全不管底下的其它任何问题而造成的。

那估计是他的Bug

“这个问题为啥还没解决呢?”

“我觉得应该是他那里边的Bug,我调不了。”

“哦……”

这个“他”可以是某一位同事,或者前同事,或者微软,或者别的什么公司,再或者某个开源代码的作者。这些个我都遇到过,比如说是另一位现在在职的同事吧。当你告诉这位同事这个Bug似乎在他那儿,并且问问什么时候解决,他也许会很愧疚的立刻调试,可最后结果却仍然是开头对话主人翁的所写代码的问题。

再比如说是微软吧,那么对话可能就会包括:“啊,SilverLight真是烂,老是内存泄漏、崩溃等……”“是啊是啊!烂死了!早知道用Flash了。”又或者会说:“微软就是烂,Java就是好。”其实,我不想比较什么SilverLight还是Flash,.NET还是Java。因为在讨论这些问题之前,先最好想想,这真的是别人的错么?相信是其他人的错是一件很简单的事情,因为这样推脱之后你就可以啥都不做了,反正不是我的错。

如果真的发现了这是别人的Bug并证明了,那倒好说。但这种特征是一种纯粹的怀疑,并没有丝毫的证明。在仔细找了自己所有可能犯的错之后,如果你怀疑是别人的问题,那请求证一下。

无图无真相!

“楼主,无图无真相啊!”

“楼主,无代码无真相啊!”

“楼主,给翻译一下啊!”

据说Linus在别人询问Linux内存管理的一个什么问题时,回答道“Read the fxxxing source code”,很多时候我也有类似的冲动。我发现在信息发达的时代,不少人的阅读能力、动手能力都严重退化了。这些人最好就是你亲自来帮他把问题解决了,他才不想了解里面到底 发生了什么。这种问题体现在博客里面,就是寄希望于你写得图文并茂,图嘛最好花里胡哨同时言简而意概,文字嘛最好大段大段的代码。其实图不是重要的,只是为了好看,重点是代码,这样他一Copy就可以直接解决他们的问题了。

比方说,Silverlight里面没有各种图像格式的编码器,于是当你希望保存Jpg的时候怎么办呢?Google一下,发现原来有人写过一个FluxJpeg的编码器。下载下来一跑,唉还真能用哎。之后就直接签入,也不捎带看一下有没有什么问题,或者设计不合理的地方。(其实真的有,会很慢,因为有大量毫无必要的数组拷贝。)

又或者说,遇到了某个Bug,搜索一下发现,哎,还真有人遇到过,而且还有代码哎!把代码扒下来一跑,发现好像解决了,至于为什么就不管了。甚至还遇到过根本就不管解决不解决问题,反正代码扒下来了就签入了的。

再比如,写一篇博客讲解如何缩减.NET编译出来的文体大小,其中提到许多概念需要先阅读微软官方的一个文档。结果,还是会有人回复说,你那个文章里面提到那么多的Blob,也不说说Blob里面都有什么,大概是很不满意吧。可是这个文档里面都有啊,难道就不能自己阅读一下?其实即便我连这个文档都没有给出,自己也应该有这个能力去进行思考,去动手寻找。

千万不要退化成一个啥都要别人给你嚼烂了才能够吞下去,吞下去也不会消化吸收的人。这样的人大概别人给的是大便,只要有代码无真相,也会照样吃下去的。若真如此,那你打算如何提高呢?

那是个对象!

“这个ExpressionVisitor,它是用来干什么的?”

“……”

“好吧,或者这么说,他是一个什么东西?”

“他是一个对象!”

“啊?”

“哦,是一个对象的实例。”

大概这样的回答,和那个微软工程师说“你在直升飞机上”差不多——反正你也不能说是错的,但是就是没什么意义。其实不知道没啥问题,人又不是神,怎么可能都知道呢?不去仔细了解和学习问题也不严重,因为你可以改。但是当你习惯性的随便找一个绝对没错但又不说明任何问题的答案,甚至似是而非的东西来对付的时候,你就离弱爆的边缘很近了。

当然,上面的对话也许是比较极端的。一个稍弱一点的对话版本是:

“这个内存泄漏是怎么造成的呢?”

[…]

编程不是绣花

编程不是绣花,没必要做到完美。

程序员很容易有洁癖,觉得不“正统”,不“完美”的解决方案是不能接受的,所以喜欢跟一个问题死磕到底,不找出一个百分百另自己满意的解决方案不肯罢休。最后往往把自己搞的筋疲力尽,耽误了进度,而最完美的方案却依然没有找到,不得不采用不那么“完美”但可行的方案,让自己沮丧。

其实解决问题最好的方法是绕过那个问题,没必要跟它死磕。当找不到更好地解决方案时,先将问题封装起来,继续推进,等以后有空了再来优化。

没必要死磕还有一个原因,那就是这个问题可能会因为功能的变动而消失,那么,当初苦苦找寻的“最佳方案”岂不是白费力气?

昨天在做一个Facebook应用时,发现官方提供的API不能实现我想要的效果,虽然我马上通过Google找到了答案,但我不信Facebook的文档会有问题,肯定是自己哪里看漏了,所以我不肯罢休,一定要找出“官方”的解决方案。结果耗费了一下午的时间,最后到下班也没达成心愿,不得不接受之前通过Google找到的答案,很是沮丧,有感而发,便有了这篇日志。

Category

Archives