线下活动 GZRuby 第 22 次活动总结

allenfantasy · 2014年12月28日 · 最后由 jasli2 回复于 2014年12月29日 · 3357 次阅读

各位 Rubyist 好!

这周六我们在广州 T.I.T 创意园的 CCIC 联合文创举行了第 22 次的 GZRuby Party,尽管天气较冷,还下起了小雨,但还是不能阻挡与会者的热情 :)

活动回顾

分享内容

以下简单总结本次活动中各位讲师带来的精彩内容,点击主题名称后的链接可以直接在讲稿网查看演讲内容。【P.S:讲稿正在整理中,会尽快上传并给到链接】

1. 高金华 -《Sass 和 Compass 在 Web 开发中的实践》 链接

Sass 是一种拓展了 CSS3 规则的样式语言,提供了变量、函数、嵌套等便于 CSS 开发的特性,并可以编译成 CSS 代码应用于生产环境中。在这个主题中,高金华详细介绍了 Sass 的基本语法及使用,并结合生动的例子演示如何利用 Sass 的新特性来对样式代码进行良好的组织。

2. 王振威 - 《你不知道的 Nginx》 链接

Nginx 是我们在生产环境中常用的 HTTP 和反向代理服务器,相信众多开发者(特别是后端)或多或少都会接触到。 但 Nginx 除了基本的反向代理、静态资源处理等功能外,还有不为人熟知的诸多应用场景。 来自 Coding.net 的王振威在演讲中介绍了 Nginx 的一些“冷门”功能,如正向代理,内部重定向,限制并发,配合 memcached 进行使用,配合 lua 进行使用等,可谓干货多多。

3. 周建平 - 《Token Based & Loose Coupling Auth in API designing》 链接

在 API 设计中,需要仔细考虑如何进行用户验证和用户权限管理;同时,如何在前后端组织同一份用户权限的信息(knowledge)也是开发者需要斟酌的问题。 来自艾道信息咨询的周建平为我们讲解了基于 JWT(Json Web Token) 的 API 验证方法:在用户登录时利用用户非敏感信息和 secret key 组装的方式生成 JWT 并返回,客户端利用收到的 Token 来进行后续的验证;同时利用验证时返回的指令集来规定客户端用户的权限,以达到前后端代码松耦合的效果。

即兴演讲环节

除了固定的讲师分享外,我们还加入了即兴演讲的环节,在场的小伙伴们就函数式语言聊起来了 ;)

最后再放上合照一张!

总结&展望

每到这个时候就会有很多人说“新的一年,新的希望”(我们也不例外,LOL)

随着本次 GZRuby 的顺利完成,2014 年的活动也告一段落了,从 1 月份的Rails Girls ,3 月份的第 17 次活动,再到本月的第 22 次活动,GZRuby 一直坚持下来,作为 Ruby 气氛并不是太浓厚的广州城的坚守。这里要感谢为活动提供场地的 Strand Beer,FocusCom,铂涛酒店,CCIC 联合文创,以及历次参加活动的讲师们和朋友们!

2015 年 GZRuby 的活动会继续进行,活动频度仍旧为 1 个月 1 次,新的活动会在官网,Ruby China 以及 GZRuby 的微信群中发布消息,同时我们也争取尽快建立 GZRuby 的微信公众号。

希望社区的朋友们继续多多支持,更欢迎为活动贡献主题,有任何意见或者建议欢迎直接联系我们。联系方式: martin at beansmile.com, allen at dxhackers.com

GZRuby 微信交流群

最后加上 GZRuby 微信交流群的二维码,欢迎感兴趣的朋友们加入!

昨天去参加了,不过现在还不知道哪位是炮哥,我好惭愧

#1 楼 @will7v 囧 rz

之前没有了解过 JWT,回去看了一下,感觉和 Rails 自带的cookie 签名机制没啥区别。更想听的是“Why jwt better”,和其他类似方案的对比,比如直接用 Rails 的 MessageVerifier 或 AES 加密 甚至直接在 account 上面加一个 api token 之类做法有什么优缺点之类的话题。还有,JWT 作为标准有什么约束力,如果标准没有人遵守其实也是一种束缚,大家各自使用自己的实现会更自由一些。

大家可以就这个帖子再讨论一下...

#2 楼 @hooooopo 竟然是第一次听说 MessageVerifier,囧。

其实“Why jwt better”应该是两个问题:Why token based?Why jwt?

Why Token?这个blog讲得比较清晰了。

如果已经决定用 Token 来作为授权的方式,那么 MessageVerifier 和 JWT 没有本质的区别。都提供了产生和验证 token 的机制。

JWT 真要说有什么优点,应该是 JWT 不是做加密而是做签名,所以可以用 JWT 传输信息,因为客户端也是可以打开 JWT 的携带的内容的。 另外,在不带来额外的工作量的前提下,兼容标准应该是值得的。

#3 楼 @jasli2 使用 Token Base 应该没什么争议,MessageVerifier 也是签名,不加密。看了源码和 JWT 实现方式几乎一样。其实自己写签名步骤也就几行代码搞定...

链接内容不错,谢谢分享。

二维码过期了 换一个吧

之前一个项目,涉及到相关的一个博客:

JWT is a recent open standard that is being driven by the international standards body IETF and has top-level backers from the technology sector (for example, Microsoft, Facebook, and Google).

The fundamental building blocks of JWT are very well understood components and the result of this is a fairly simple spec, which is available here http://tools.ietf.org/html/draft-jones-json-web-token-10. There are a lot of open source implementations of the JWT spec that cover most modern technologies. This means that you can get JWT single sign-on set up without much difficulty.

One thing to be aware of is that the JWT payload is merely encoded and signed, not encrypted, so don't put any sensitive data in the hash table. JWT works by serializing the JSON that is being transmitted to a string. It then base 64 encodes that string and then makes an HMAC of the base 64 string which depends on the shared secret. This produces a signature that the recipient side can use to validate the user.

感谢 @allenfantasy 的总结,当天的讲稿已经上传,allen 会尽快更新到本帖,请大家多多关注!

更新了讲稿和交流群的二维码 :)

#4 楼 @hooopo 没有看源码,汗。

其实我们在设计 API 的时候,主要考虑的原则还是在不增加很大工作量的情况下,尽量向标准(或者准标准)靠拢。比如 用 HTTP Header 传输 Token 以及 API 的版本,用 JWT draft 来实现 Token。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号