Session Management Cheat Sheet

OWASP出品的关于session的非常详细的cheat sheet。 重点讲了如何安全地管理session。 session做为一种和用户名&密码等效的认证手段，session管理的安全性是很重要的。

Scale Out Multi-Tenant Apps based on Ruby on Rails

一些ORM框架，比如EclipseLink，自带了多租户的实现。 这篇文章介绍了一个在Rails ActiveRecord之上的多租户实现。

Cookies vs Tokens: The Definitive Guide

JSON Web Token (JWT)和基于cookie的认证机制的比较。

基于cookie的authentication需要在服务端记状态。 而JWT是stateless的，这样服务的水平扩展性更好（不用考虑类似session replication这样的问题）。 不像cookie，JWT可以cross domain。 使用JWT后，API的使用者可以不局限于浏览器，这样对mobile app更友好。 session机制需要一些服务端查找，相比而言可能JWT的性能会好点。

想起了Rails的EncryptedCookieStore。 EncryptedCookieStore和JWT一样也是完全存在于client端。 和JWT的一个不同点是EncryptedCookieStore会加密内容，JWT不会（JWT只是sign）。

基于cookie的session机制可以在服务端让session失效。 JWT则需要在客户端做失效。

Class Loader HOW-TO

这篇文档介绍了Tomcat的class loader hierarchy和加载类时目录的搜索次序。 Tomcat的各个web app会共用一些class loader，也有属于各自的class loader（为了隔离）。

      Bootstrap
          |
       System
          |
       Common
       /     \
  Webapp1   Webapp2 ...

当WebappX的class loader加载一个类时，会先在WebappX的目录里找类定义 （这和普通Java程序的class loader parent-delegation model略有不同）。 但是也有例外，比如加载JRE的基础类时还是会先委托父class loader去加载。

Tomcat的类加载行为也是可以配置的（通过<Loader delegate="true"/>）。

因为每个web app都有自己的class loader，要防止class loader的泄漏。

Tomcat的文档还是比较详尽的，没事可以多看看。

Technology Radar

Thoughtworks对一些技术和工具（包括新的和老的）的评价和看法。 会推荐一些新的技术和工具，也会评估已存在的工具和技术是不是还能继续适用。 Technology Radar会定期更新，一般一年有两到三期。

没事可以看一看，起码可以了解一堆名词。

Storing User Passwords Securely: hashing, salting, and Bcrypt

在存储密码的数据库被攻破的前提下，破解密码的成本越高则密码的安全性就越高。 一般来说，密码在存储到数据库前都经过hash加密。 需要考虑hash函数的性能对密码安全性的影响。 比如对于SHA256来说，当前的普通计算机能在一秒内计算数百万的hash值，定制的计算机则可以提供每秒数十亿次的hash运算。 在这种情况下，很多密码安全的设计都变得不再安全。

首先，最不安全的方式是明文存储密码。 其次，对密码明文进行sha1加密、对密码明文进行sha1加密时加上固定的salt值、为每个用户分配不同的salt值都是不安全的。

推荐使用bcrypt加密密码。 bcrypt相比sha1等来说更慢，这意味着破解密码的cpu成本更高。 比如log_rounds值设为10时，大概需要100毫秒来计算hash值。 还可以通过增加log_rounds值来抵消未来计算机运算能力的提高。 一些bcrypt实现还原生支持per-user-salt。

Dropbox也主要采用了per-user-salt加bcrypt来存储用户密码。 Dropbox在用bcrypt hash之前，会先用SHA512对密码做预处理——把密码hash成512 bit的定长字符串。 预处理有两个作用：一是对于很短的密码，提高它的entropy（熵）；二是防止输入密码过长造成潜在的DoS attacks风险（bcrypt很“慢”）。 Dropbox还引入了global pepper（既有“盐”又有“胡椒粉”）——对bcrypt的hash值再用AES256做进一步的加密。 pepper存储在数据库之外的地方。AES256是对称加密，方便未来更新pepper值。

Ruby on Rails Changelogs

Rails从0.9.3版本开始到当前版本的所有Changelogs。 自“底”向“上”过一遍这些Changelogs，可以了解一个web框架（该有）的功能和演化。

Changelog（总）是了解一个软件（新）功能的最佳文档。

Java performance tuning tips or everything you want to know about Java performance in 15 minutes

关于Java性能调优的一篇文章，其内容是java-performance.info上所有文章的归纳总结。 主要侧重于Java代码本身的调优，不涉及JVM参数。 推荐一看。

Avoiding Benchmarking Pitfalls on the JVM

基准测试看似简单，但是由于JVM会在运行时做优化，可能使得基准测试的结果失去意义。

比如JVM如果“看到”接口只有一种实现时，会对接口方法的调用做优化。 如果在后续运行中“看到”很多的接口实现时，则会抛弃掉之前的优化。 这会导致对第二个接口实现的benchmark结果变得不准确。 其它JVM优化手段还有dead-code elimination、constant folding等等。

所谓基准测试，意味着有baseline，有对比，JVM的优化会导致对比的某一方得到了“不公平的”优待，使得对比的结果失去了意义。

文章推荐使用jmh来做基准测试。

it was developed as part of the OpenJDK project

JMH is popular for writing microbenchmarks, that is, benchmarks that stress a very specific piece of code. …

Aleksey Shipilëv: One Stop Page

Aleksey Shipilëv的博客。

Aleksey is working on Java performance for 10+ years. Today he is employed by Red Hat, where he does OpenJDK development and performance work.