多喝水

我去淘宝搜了一家，发现地址就在徐家汇实业公寓楼上，离我现在上班的地方很近，然后我就拿电脑直接过去换了，已经换好，现在已经回来继续上班了。感觉还不错，不知道用久了会怎样。

是不是搞前端就不会有什么大问题

big cock

学英语再自学计算机，好找女朋友和工作

原型和设计稿还是有差别的吧，用 sketch 画原型不累死，还是用 axure 省事吧

@julyclyde

如果直接使用数据库存储 token 的话那会方便吊销 token ，但是这种把不该持久化的东西持久化，总觉的不太好吧。

我看到一个修改密码后吊销 token 的解决方案： http://stackoverflow.com/questions/28759590/best-practices-to-invalidate-jwt-while-changing-passwords-and-logout-in-node-js
自包含的这种 token 实现吊销功能也是要单独再存储一个类似 InvalidTokenDB 的关系，觉得这个可以用 redis 来存储，方便处理过期 token 。

@julyclyde 觉得这样要再单独存储一层关系吧，比如 user id 对应的 token 列表。当要吊销的时候再根据 user id 找到下面的所有 token ，把他们从服务端清除。

@julyclyde user 对 token 是一对多关系并且不是自包含的，那么 token 可以是一个随机字符串并作为 key ， user id 作为 value ，服务端把这种 key-value 关系存储下来。这样子可以实现一对多关系，并且也不是自包含的。但是这样子服务端吊销某个用户的 token 该如何实现？因为一般缓存总不能根据 value 去查询。不太明白，还望讲解一些。或者不应该是这种 key-value 的实现方式？

@julyclyde 服务器可以吊销 token ，是不是意味着要以用户 id 作为 key 来存储，这样是不是就没法实现一个账户多处登录？

@flyingghost 同意！我觉得这个才是基于 session 和 token 两种认证的最大区别，你这里说的更加清楚。那些说 token 也要在服务端存储的其实讲的还是 session 的思想，并没有理解这种区别。

@neutrino @shiji @bobuick jwt 确实是基于 token 认证的一种比较好的实现方法，而且是行业标准 rfc7519 ，可以通过解码确认用户身份，这个我之前不知道，学习了。
我看到的 token 实现方式有多种，主要参考了这个： http://security.stackexchange.com/questions/81756/session-authentication-vs-token-authentication

@neutrino 我理解的 oauth2.0 一般都是给第三方授权使用的，本站的用户授权直接登录就好了吧？

不错，挺难得的， pelican 的也可以参考

做个网站

微信改个性别不难啊

@uuxia 小伙子挺不错的

支持！