Generate URL-safe SGIDs #98
Conversation
|
I didn’t realize that Global ID supports Rails 4.1, where this isn’t so tractable. |
|
Given that Rails 4.1 is not maintained anymore, we can drop support to it now. We just need to bump globalid to 0.4.0 |
|
Great! I’ve still got a failure with 4.2 on Ruby 1.9.3 to address. I’ll look into it tomorrow. |
|
Tests are passing against Rails 4.2 and 5.0 now. All set? |
|
Yup! Going to remove the 4.1 build env now and then release this. |
|
Think the GlobalID builds are waiting for the Rails builds to finish before starting, so postponing the release to later today. Got most of it wired up though and smoke tested using the Active Job tests with the 0.4.0 source. |
We use SGIDs in some URLs sent via email from Basecamp. Since Basecamp 3’s launch, we’ve heard reports of broken links in emails from customers whose mail clients decode slashes in URL-encoded SGIDs.
For example, errant mail clients turn an SGID such as (a) below, which Rails parses as one path segment, into (b), which Rails parses as two path segments.
Unfortunately, we’ve been unable to identify exactly which mail clients mangle SGIDs in this way.
Global ID already ensures unsigned GIDs are safe for use in URLs. To circumvent problematic mail clients, it can do the same for signed GIDs. This PR implements a custom message verifier that prefers URL-safe base64 encoding,
GlobalID::Verifier, and makes it the default for SGID generation.GlobalID::Verifieraccepts SGIDs generated withActiveSupport::MessageVerifierfor backwards compatibility./cc @jeremy