Cookiekeyfile

[mgkuhn]

• AACookieKey/AAHeaderKey can now load key bytes from file:filename or file:/dev/urandom (fixes Allow AACookieKey/AAHeaderKey to read from a file (e.g. with file:// syntax) #10)
• updated authorization examples to Apache 2.4

[jw35]

Two thoughts:

• The documentation should probably mention that using file:/dev/urandom as the value of AACookieKey will have the side effect of triggering a round trip to Raven for all currently-authenticated users every time Apache is restarted/reloaded. While not a major issue, this will, for example, result in the loss of POST data (see Handle authentication triggered by HTTP POST better #20). Using file:/dev/urandom will also be problematic in many clustering configurations where requests may be handled by different copies of Apache at different times.

• Using file:/dev/urandom with AAHeaderKey is pointless. The whole point of this directive is to establish a shared secret that allows other systems to verify who set particular headers. While very secure, a value that no one knows and that changes each time Apache is restarted isn't really useful here. The documentation should probably also mention this.

[mgkuhn]

The mention of file:/dev/urandom is a bit experimental. I don't mind if you drop it from the documentation entirely if you don't find it useful, or potentially confusing. The file:/dev/urandom use case is the main reason for why I limited the number of bytes to be read to between 16 and 64, such that you can read from an infinitely-long character device, and are also protected from the pitfall that Linux /dev/random can deliver fewer bytes than requested (due to lack of estimated entropy).