Signer usage impacted by default algorithm changes

[abn]

This relates to #111 and #112. We were impacted by the change in default algorithm in our usage of TimestampSigner. The impact is probably lower as the services recovered without intervention and/or any visible user impact. We noticed it due to #112.

Raising this issue to ask if the Signer implementation also needs a fallback digest method defaulting to SHA-512 in order prevent any further breakages.

[joshfriend]

User of JSONWebSignatureSerializer here, we noticed the change when prod logs started blowing up with BadSignature exceptions being logged. Fortunately, clients just go request a new token from the login endpoint which then uses the HS512 algorithm instead of the old HS256 that used to be the default.

For now, we are just using algorithm_name="HS256" when creating the serializer, but I don't understand why the algorithm isn't inferred from the JWT header.

[joshfriend]

Oh yeah, the none algorithm 🤦‍♂️

[joshfriend]

Having educated myself about the alg header, I think that this issue should be closed since the hash algorithm change happened across a major version release and was documented in the changelog.

[davidism]

1.1 went back to the original settings, 1.0 was yanked, so except for in that window during the initial 1.0 release, installing will get a release that doesn't break things. If you do need to upgrade, you can use a shim similar to #120 (comment).