Remove Rack::Auth::Digest - #2361
Merged
Merged
Conversation
Member
|
Let's document this in UPGRADING, please? I think we can start following major version semver from here, and bump the version of Grape to 2.0 in this PR since this is a visibly breaking change? Could you please do it? |
…/grape into remove-Rack-Auth-Digest
Contributor
Author
|
Sure, I updated README, CHANGELOG and also UPGRADING. Let me know if it's not enough or if I miss something. |
dblock
requested changes
Oct 25, 2023
dblock
left a comment
dblock
left a comment
Member
There was a problem hiding this comment.
3 more places: The README has a "Stable Version" section that will need to say next is 2.0.
Member
|
README#stable-release still needs a bump to 2.0, please? |
Contributor
Author
Oops, I updated it by 4905cc6. |
dblock
approved these changes
Oct 25, 2023
ericproulx
added a commit
that referenced
this pull request
Aug 1, 2026
Nothing it could reach has existed since 2.0.0. #2361 removed Rack::Auth::Digest and Grape's :http_digest strategy after Rack 3 dropped digest authentication, but Grape::Middleware::Auth::DSL#http_digest survived and kept recording its settings, so an API declaring it still booted -- and then raised Grape::Exceptions::UnknownAuthStrategy on the first request, from inside the middleware build, as an uncaught exception rather than a response. A misconfiguration only visible in production. The 4.0 UPGRADING notes still used `auth :http_digest, realm: 'API', opaque: 'secret'` as a worked example of a supported call, so the documentation pointed at it too. That section is rewritten, and the removal documented. Removing the sugar rather than validating the strategy when `auth` is called: #auth deliberately records whatever it is given and resolves the strategy when the middleware is built, which is what lets an application register its own. That contract is specified -- validating early breaks it, and would break registering a strategy after the API class is defined. `auth :http_digest` therefore still works for anyone who registered one; only the sugar is gone, along with the two defaults it supplied (realm 'API Authorization', opaque 'secret'), which UPGRADING spells out. The DSL specs used :http_digest as their example label for #auth itself. They now use a neutral :custom, which keeps the distinction the specs are actually about: #auth records a label, the strategy behind it is looked up later. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ericproulx
added a commit
that referenced
this pull request
Aug 1, 2026
Nothing it could reach has existed since 2.0.0. #2361 removed Rack::Auth::Digest and Grape's :http_digest strategy after Rack 3 dropped digest authentication, but Grape::Middleware::Auth::DSL#http_digest survived and kept recording its settings, so an API declaring it still booted -- and then raised Grape::Exceptions::UnknownAuthStrategy on the first request, from inside the middleware build, as an uncaught exception rather than a response. A misconfiguration only visible in production. The 4.0 UPGRADING notes still used `auth :http_digest, realm: 'API', opaque: 'secret'` as a worked example of a supported call, so the documentation pointed at it too. That section is rewritten, and the removal documented. Removing the sugar rather than validating the strategy when `auth` is called: #auth deliberately records whatever it is given and resolves the strategy when the middleware is built, which is what lets an application register its own. That contract is specified -- validating early breaks it, and would break registering a strategy after the API class is defined. `auth :http_digest` therefore still works for anyone who registered one; only the sugar is gone, along with the two defaults it supplied (realm 'API Authorization', opaque 'secret'), which UPGRADING spells out. The DSL specs used :http_digest as their example label for #auth itself. They now use a neutral :custom, which keeps the distinction the specs are actually about: #auth records a label, the strategy behind it is looked up later. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> (cherry picked from commit 2e12a20)
ericproulx
added a commit
that referenced
this pull request
Aug 1, 2026
Nothing it could reach has existed since 2.0.0. #2361 removed Rack::Auth::Digest and Grape's :http_digest strategy after Rack 3 dropped digest authentication, but Grape::Middleware::Auth::DSL#http_digest survived and kept recording its settings, so an API declaring it still booted -- and then raised Grape::Exceptions::UnknownAuthStrategy on the first request, from inside the middleware build, as an uncaught exception rather than a response. A misconfiguration only visible in production. The 4.0 UPGRADING notes still used `auth :http_digest, realm: 'API', opaque: 'secret'` as a worked example of a supported call, so the documentation pointed at it too. That section is rewritten, and the removal documented. Removing the sugar rather than validating the strategy when `auth` is called: #auth deliberately records whatever it is given and resolves the strategy when the middleware is built, which is what lets an application register its own. That contract is specified -- validating early breaks it, and would break registering a strategy after the API class is defined. `auth :http_digest` therefore still works for anyone who registered one; only the sugar is gone, along with the two defaults it supplied (realm 'API Authorization', opaque 'secret'), which UPGRADING spells out. The DSL specs used :http_digest as their example label for #auth itself. They now use a neutral :custom, which keeps the distinction the specs are actually about: #auth records a label, the strategy behind it is looked up later. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> (cherry picked from commit 2e12a20)
ericproulx
added a commit
that referenced
this pull request
Aug 1, 2026
Nothing it could reach has existed since 2.0.0. #2361 removed Rack::Auth::Digest and Grape's :http_digest strategy after Rack 3 dropped digest authentication, but Grape::Middleware::Auth::DSL#http_digest survived and kept recording its settings, so an API declaring it still booted -- and then raised Grape::Exceptions::UnknownAuthStrategy on the first request, from inside the middleware build, as an uncaught exception rather than a response. A misconfiguration only visible in production. The 4.0 UPGRADING notes still used `auth :http_digest, realm: 'API', opaque: 'secret'` as a worked example of a supported call, so the documentation pointed at it too. That section is rewritten, and the removal documented. Removing the sugar rather than validating the strategy when `auth` is called: #auth deliberately records whatever it is given and resolves the strategy when the middleware is built, which is what lets an application register its own. That contract is specified -- validating early breaks it, and would break registering a strategy after the API class is defined. `auth :http_digest` therefore still works for anyone who registered one; only the sugar is gone, along with the two defaults it supplied (realm 'API Authorization', opaque 'secret'), which UPGRADING spells out. The DSL specs used :http_digest as their example label for #auth itself. They now use a neutral :custom, which keeps the distinction the specs are actually about: #auth records a label, the strategy behind it is looked up later. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> (cherry picked from commit 2e12a20)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Remove
Rack::Auth::Digest.As far as I understand, #2294 reaches a conclusion that removing
Rack::Auth::Digestis the way to go.(It's my first time to make a PR to this repository. So please let me know if I miss something)