使用Openid可以算是高性能站点的措施之一吗？

[Woody]

单纯的认为 如果能合理的使用openid在网站中作用的整合 我想可以替网站剩下很多资源，其中包括注册和用户管理。
gravatar的应用应该可以算的上是一种openid的应用延伸。

[Jianquan LIU]

严重同意这个观点。
偷偷地问，现在Tencent有针对openid提供QQ用户的认证做努力吗？
尽管openid已经不是一个新鲜的话题，但还是值得做的。

2009/5/25 Woody <unix...@gmail.com>:

> 单纯的认为 如果能合理的使用openid在网站中作用的整合 我想可以替网站剩下很多资源，其中包括注册和用户管理。
> gravatar的应用应该可以算的上是一种openid的应用延伸。
> >
>

--
Jianquan Liu
Computer Science, University of Tsukuba, Japan
http://dblab.is.tsukuba.ac.jp/~ljq/

[colin]

合理的使用openid的确可以为站点带来一些非常实际的好处，比如像woody说削减了用户管理和注册逻辑等，更重要是对于已有openid的用户来
说也无疑是一件好事情。

但是使用openid的代价却恰恰正是性能的牺牲，站点必须和openid服务器进行频繁的通信，这使得系统又不得不引入了网络I/O的制约，所以单纯
从性能上讲，本地化的帐号系统是性能的首选。

当然，openid也是一个商业产品，它并不是技术层面的一个必然产物，你可以权衡利弊来使用它。

On May 25, 10:20 pm, Jianquan LIU <ryuken...@gmail.com> wrote:
> 严重同意这个观点。
> 偷偷地问，现在Tencent有针对openid提供QQ用户的认证做努力吗？
> 尽管openid已经不是一个新鲜的话题，但还是值得做的。
>

> 2009/5/25 Woody <unix1...@gmail.com>:

[unix1983]

opendi现阶段最困难的问题是如何选一个有公信力的第三方，现在使用的openid大多是email，其实NIS OPENLADP都可以作为其应用。

现在只知道gmail提供openid的接口。

 

另外我觉得使用openid的站点应该和openid提供方不存在很频繁的通信（猜的 另外也是觉得没必要 只要session没过期站点没理由频繁向openid方请求什么，另外openid方的作用只是个验证，又不存放什么信息、比如帖子和blog之类的。），他其实就是个验证机制，站点使用openid放提供的接口，用户登录的时候将email地址和密码一起发送验证（openid现在不敢大肆推广的原因之一就是，帐号的安全问题，站点如果截获邮件地址和密码也是很恐怖的 -.- ），openid放接到验证请求进行核实，如果信息正确返回一个true给站点就OK了，站点将其地址作为username存在session中。（我没做过使用openid的站点 流程是猜测的）

 

 

2009-05-26

---

unix1983

---

发件人： colin

发送时间： 2009-05-25  23:59:54

收件人： 《构建高性能Web站点》读者讨论组

抄送：

主题： Re: 使用Openid可以算是高性能站点的措施之一吗？

合理的使用openid的确可以为站点带来一些非常实际的好处，比如像woody说削减了用户管理和注册逻辑等，更重要是对于已有openid的用户来

说也无疑是一件好事情。

但是使用openid的代价却恰恰正是性能的牺牲，站点必须和openid服务器进行频繁的通信，这使得系统又不得不引入了网络I/O的制约，所以单纯

从性能上讲，本地化的帐号系统是性能的首选。

当然，openid也是一个商业产品，它并不是技术层面的一个必然产物，你可以权衡利弊来使用它。

On May 25, 10:20 pm, Jianquan LIU <ryuken...@gmail.com> wrote:

> 严重同意这个观点。

> 偷偷地问，现在Tencent有针对openid提供QQ用户的认证做努力吗？

> 尽管openid已经不是一个新鲜的话题，但还是值得做的。

>

> 2009/5/25 Woody <unix1...@gmail.com>:

[Kevin]

可能unix1983对openid有一些误解。
openid并不需要用户提供邮件地址和密码，用户只需要提供一个带有用户名信息的URL，如http://seaprince.myopenid.com/，然后系统重定向到相关的openid提供商，在提供商处完成登陆认证后跳转回来。如果你在openid提供商处的会话还没有过期，则可以直接完成认证过程，不需要输入用户名密码。
这个在某种程度上讲，是增强了账号的安全。因为，openid提供方是你自己选的，可以信任，而用户名密码的认证过程也是在这个可以信任的第三方完成的。

2009/5/26 unix1983 <unix...@gmail.com>:

[unix1983]

惭愧啊 =。= 没有实践就没有发言权  刚看到kevin对openid的解释 让我对openid更感兴趣了 今天就开始好好研究一下

http://woody-xu.myopenid.com/

 

 

2009-05-26

---

unix1983

---

发件人： Kevin

发送时间： 2009-05-26  09:05:01

收件人： highperformanceweb

抄送：

主题： Re: Re: 使用Openid可以算是高性能站点的措施之一吗？

可能unix1983对openid有一些误解。

openid并不需要用户提供邮件地址和密码，用户只需要提供一个带有用户名信息的URL，如http://seaprince.myopenid.com/，然后系统重定向到相关的openid提供商，在提供商处完成登陆认证后跳转回来。如果你在openid提供商处的会话还没有过期，则可以直接完成认证过程，不需要输入用户名密码。

这个在某种程度上讲，是增强了账号的安全。因为，openid提供方是你自己选的，可以信任，而用户名密码的认证过程也是在这个可以信任的第三方完成的。

2009/5/26 unix1983 <unix...@gmail.com>:

[colin]

我目前也没有实际在应用中使用过openid，不过随后就要在自己的一个新项目中使用了，无论如何，站点和openid服务器的通信是少不了的，至于是
否频繁，我想这取决于验证的粒度需求，想请教一下Kevin，帐号验证采用了url跳转而不是Web API，这往往用于用户登录，一旦登录成功重定向
回站点后，openid是如何设计用户会话信息本地化的？如果有完整本地化（比如登录成功跳转URL中附带了用户ID和Session等参数），那如何
保证过期检查，如果没有，那么每次获取用户登录状态都需要向openid服务器进行API请求，这时候URL跳转显然不合适。

On May 26, 9:04 am, Kevin <com...@gmail.com> wrote:
> 可能unix1983对openid有一些误解。
> openid并不需要用户提供邮件地址和密码，用户只需要提供一个带有用户名信息的URL，如http://seaprince.myopenid.com/，然后系统重定向到相关的openid提供商，在提供商处完成登陆认证后跳转回来。如果你在openid提供商处的会话还没有过期，则可以直接完成认证过程，不需 要输入用户名密码。
> 这个在某种程度上讲，是增强了账号的安全。因为，openid提供方是你自己选的，可以信任，而用户名密码的认证过程也是在这个可以信任的第三方完成的。
>

> 2009/5/26 unix1983 <unix1...@gmail.com>:

>
> > opendi现阶段最困难的问题是如何选一个有公信力的第三方，现在使用的openid大多是email，其实NIS OPENLADP都可以作为其应用。
> > 现在只知道gmail提供openid的接口。
>
> > 另外我觉得使用openid的站点应该和openid提供方不存在很频繁的通信（猜的 另外也是觉得没必要

> > 只要session没过期站点没理由频繁向openid方请求什么，另外openid方的作用只是个验证，又不存放什么信息、比如帖子和blog之类的。），他 其实就是个验证机制，站点使用openid放提供的接口，用户登录的时候将email地址和密码一起发送验证（openid现在不敢大肆推广的原因之一就是，帐 号的安全问题，站点如果截获邮件地址和密码也是很恐怖的

[Kevin]

colin兄：

我说的是表现形式，我并没有否认站点和openid服务器存在通信。并且，不管从哪个角度，这个通信都是必须的。

大概是这么个流程：
1. 用户填入URL，重定向到openid服务器进行认证
2. 成功后返回站点
3. 站点向openid服务器确认这个会话的有效，并且可以读取用户的公开信息
4. 把需要的信息入库存档，初始化本地会话
5. 完成登录进程

2009/5/26 colin <it.g...@hotmail.com>:

[colin]

感谢Kevin兄的介绍，我大概了解了登录的机制，那么对于Session的持久化和管理，以及cookies策略，是否可以认为还是由站点自己来维
护。

另外我想了解一下，按照你的介绍，站点在用户登录后就将用户的session信息取回进行本地存储，那么如何保证session有效性检查？我不知道
Openid是否有全局注销的操作？如果有的话，那集成它的所有站点的session都应该过期吧。

On May 26, 11:03 am, Kevin <com...@gmail.com> wrote:
> colin兄：
>
> 我说的是表现形式，我并没有否认站点和openid服务器存在通信。并且，不管从哪个角度，这个通信都是必须的。
>
> 大概是这么个流程：
> 1. 用户填入URL，重定向到openid服务器进行认证
> 2. 成功后返回站点
> 3. 站点向openid服务器确认这个会话的有效，并且可以读取用户的公开信息
> 4. 把需要的信息入库存档，初始化本地会话
> 5. 完成登录进程
>

> 2009/5/26 colin <it.guo...@hotmail.com>: