Fix hash_application_secrets fallback not upgrading secret on access by Copilot · Pull Request #1801 · doorkeeper-gem/doorkeeper

Copilot · 2026-03-17T16:16:11Z

hash_application_secrets fallback: :plain could find applications stored with plain secrets, but unlike access tokens and grants, never upgraded those secrets to the active hashing strategy. The upgrade path through upgrade_fallback_value was only wired up in AccessGrantMixin and AccessTokenMixin (via find_by_plaintext_token), not for applications.

Changes

application_mixin.rb — by_uid_and_secret now explicitly tries the primary strategy first, then the fallback strategy with the upgrade embedded directly in the fallback path — mirroring the find_by_plaintext_token → find_by_fallback_token → upgrade_fallback_value pattern used by tokens and grants. secret_matches? remains a pure comparison predicate with no side effects:

# Try the primary (active) secret strategy first.
if !secret.nil? && !app.secret.nil? &&
    secret_strategy.secret_matches?(secret.to_s, app.secret.to_s)
  return app
end

# Fall back to the previous strategy if configured, upgrading on success
# to migrate the stored secret to the active strategy.
if fallback_secret_strategy && !secret.nil? && !app.secret.nil? &&
    fallback_secret_strategy.secret_matches?(secret.to_s, app.secret.to_s)
  upgrade_fallback_value(app, :secret, secret)
  return app
end

hashing_shared_context.rb — Added "with application hashing and fallback lookup enabled" shared context (configures hash_application_secrets fallback: :plain).
application_spec.rb — Added test verifying that a plain secret is upgraded to SHA256 on first access via by_uid_and_secret, and that subsequent lookups succeed via the hashed value.

Original prompt

This section details on the original issue you should resolve

<issue_title>fallback on hash_application_secrets does not upgrade secret when accessed</issue_title>
<issue_description>The Doorkeeper docs outline that, similar to access grants and access tokens, you can choose to encrypt application secrets and if you do this with existing applications, it will "upgrade" your secrets to be encrypted when they are accessed.

To enable plain values to be found and upgraded (to your active strategy, SHA256 by default) when it is accessed, you may use the following statement: hash_application_secrets fallback: :plain

I implemented this in my service and realized it does not use the upgrade path like access tokens and grants does. The method find_by_plaintext_token that eventually calls upgrade_fallback_value in SecretsStorable is only called in the AccessGrantMixin and AccessTokenMixin, not the ApplicationMixin. This difference in upgrading is also shown in tests between the types.

It's possible this could be checked in secret_matches? for an application in ApplicationMixin here.</issue_description>

<agent_instructions>Check it and if changes required - prepare a PR</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes fallback on hash_application_secrets does not upgrade secret when accessed #1780

📍 Connect Copilot coding agent with Jira, Azure Boards or Linear to delegate work to Copilot in one click without leaving your project management tool.

Co-authored-by: nbulaj <[email protected]>

nbulaj · 2026-03-19T19:02:44Z

@copilot should it be implemented using secret storable pattern? Like in find_by_plaintext_token which uses find_by and then fallbacks to find_by_fallback_token in case not found. I don't think your solution works when we lookup for Application using by_uid_and_secret (which is used internally by Doorkeeper gem)

Co-authored-by: nbulaj <[email protected]>

Copilot · 2026-03-19T19:07:56Z

@copilot should it be implemented using secret storable pattern? Like in find_by_plaintext_token which uses find_by and then fallbacks to find_by_fallback_token in case not foun...

Good point. Moved the upgrade logic out of secret_matches? (which should stay a pure predicate) and into by_uid_and_secret, following the same pattern as find_by_plaintext_token → find_by_fallback_token → upgrade_fallback_value. After confirming a match via secret_matches?, by_uid_and_secret calls upgrade_fallback_value when the primary strategy didn't match (meaning fallback matched). Commit: c02a6fd.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

coveralls.io
- Triggering command: /usr/bin/ruby3.2 ruby3.2 /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/bin/rspec spec/models/doorkeeper/application_spec.rb --format documentation -I /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/gems/prism-1.9.-ffile-prefix-map=BUILDDIR=. --gdwarf-5 --64 -o regexp.o /tmp/cc9ToBQe.s -I by-3.2.0 -I 0/include -I 0/ext -I as (dns block)
- Triggering command: /usr/bin/ruby3.2 ruby3.2 /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/bin/rspec spec/models/doorkeeper/ --format progress -I /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/gems/prism-1.9.0/ext --gdwarf-5 --64 -o token_type.o /tmp/ccA7wHcW.s -I ruby-3.2.0 ackward undle/ruby/3.2.0-I -I undle/ruby/3.2.0-I oorkeeper/vendor. -gcc (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled
Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

nbulaj · 2026-04-24T07:58:30Z

@copilot shouldn't fallback happen before return unless app.secret_matches?(secret) is called? Since secret is hashed

…flow Agent-Logs-Url: https://github.com/doorkeeper-gem/doorkeeper/sessions/4ed929bb-0df5-468c-8913-2d5909a973e9 Co-authored-by: nbulaj <[email protected]>

Copilot · 2026-04-24T08:05:12Z

@copilot shouldn't fallback happen before return unless app.secret_matches?(secret) is called? Since secret is hashed

Yes, fixed in 921428f. by_uid_and_secret now tries the primary strategy first and returns immediately on match, then explicitly handles the fallback path with the upgrade integrated — so the fallback check (with upgrade) happens as its own step, not as a post-check after a single secret_matches? gate.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

coveralls.io
- Triggering command: /usr/bin/ruby3.2 ruby3.2 /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/bin/rspec spec/models/doorkeeper/application_spec.rb --format documentation -I /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/gems/prism-1.9.0/ext --gdwarf-5 --64 -o regexp.o /tmp/cc0qFKr2.s -I by-3.2.0 -I undle/ruby/3.2.0-Wdate-time -I undle/ruby/3.2.0compiling -I as (dns block)
- Triggering command: /usr/bin/ruby3.2 ruby3.2 /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/bin/rspec spec/models/doorkeeper/application_spec.rb --format documentation -I /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/gems/prism-1.9.0/ext --gdwarf-5 --64 -o token_type.o /tmp/ccWVtk0d.s -I _64-linux-gnu/ru-I pointer undle/ruby/3.2.0-I p=BUILDDIR=. undle/ruby/3.2.0-I otection as (dns block)
- Triggering command: /usr/bin/ruby3.2 ruby3.2 /home/REDACTED/work/doorkeeper/doorkeeper/vendor/bundle/ruby/3.2.0/bin/rspec spec/models/doorkeeper/application_spec.rb --gdwarf-5 --64 -o iseq_collector.o /tmp/ccz4BQjx.s 3 0/ext /usr/include/rub. -gcc -I 86_64-linux-gnu/-I uby-3.2.0/ruby/b/usr/include/ruby-3.2.0/ruby/backward by-3.2.0 -I kward ork/doorkeeper/d. x86_64-linux-gnu-I (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled
Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

github-actions · 2026-04-24T08:12:31Z

-        app
+        # Try the primary (active) secret strategy first.
+        if !secret.nil? && !app.secret.nil? &&
+            secret_strategy.secret_matches?(secret.to_s, app.secret.to_s)


📝 [rubocop] <Layout/MultilineOperationIndentation> _{reported by reviewdog 🐶}
Align the operands of a condition in an if statement spanning multiple lines.

github-actions · 2026-04-24T08:12:31Z

+        # to migrate the stored secret to the active strategy (mirrors the
+        # find_by_plaintext_token -> find_by_fallback_token pattern).
+        if fallback_secret_strategy && !secret.nil? && !app.secret.nil? &&
+            fallback_secret_strategy.secret_matches?(secret.to_s, app.secret.to_s)


📝 [rubocop] <Layout/MultilineOperationIndentation> _{reported by reviewdog 🐶}
Align the operands of a condition in an if statement spanning multiple lines.

Initial plan

7152cba

Copilot AI assigned Copilot and nbulaj Mar 17, 2026

Copilot started work on behalf of nbulaj March 17, 2026 16:16 View session

Fix hash_application_secrets fallback to upgrade secret when accessed

eb94e65

Co-authored-by: nbulaj <[email protected]>

Copilot AI changed the title ~~[WIP] Fix fallback on hash_application_secrets upgrade issue~~ Fix hash_application_secrets fallback not upgrading secret on access Mar 17, 2026

Copilot AI requested a review from nbulaj March 17, 2026 16:28

Copilot finished work on behalf of nbulaj March 17, 2026 16:28

Copilot started work on behalf of nbulaj March 19, 2026 19:02 View session

Rework: move upgrade logic from secret_matches? into by_uid_and_secret

c02a6fd

Co-authored-by: nbulaj <[email protected]>

Copilot finished work on behalf of nbulaj March 19, 2026 19:08

nbulaj mentioned this pull request Mar 25, 2026

fallback on hash_application_secrets does not upgrade secret when accessed #1780

Open

nbulaj marked this pull request as ready for review March 27, 2026 08:22

Copilot started work on behalf of nbulaj April 24, 2026 07:58 View session

Refactor: integrate fallback upgrade directly into by_uid_and_secret …

921428f

…flow Agent-Logs-Url: https://github.com/doorkeeper-gem/doorkeeper/sessions/4ed929bb-0df5-468c-8913-2d5909a973e9 Co-authored-by: nbulaj <[email protected]>

Copilot finished work on behalf of nbulaj April 24, 2026 08:06

github-actions Bot reviewed Apr 24, 2026

View reviewed changes

Comment thread lib/doorkeeper/models/application_mixin.rb

github-actions Bot reviewed Apr 24, 2026

View reviewed changes

Comment thread spec/models/doorkeeper/application_spec.rb

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix hash_application_secrets fallback not upgrading secret on access#1801

Fix hash_application_secrets fallback not upgrading secret on access#1801
Copilot wants to merge 4 commits intomainfrom
copilot/fix-fallback-on-hash-application-secrets

Copilot AI commented Mar 17, 2026 •

edited

Loading

Uh oh!

nbulaj commented Mar 19, 2026

Uh oh!

Copilot AI commented Mar 19, 2026 •

edited

Loading

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

nbulaj commented Apr 24, 2026

Uh oh!

Copilot AI commented Apr 24, 2026 •

edited

Loading

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

github-actions Bot Apr 24, 2026

Uh oh!

github-actions Bot Apr 24, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Copilot AI commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Comments on the Issue (you are @copilot in this section)

Uh oh!

nbulaj commented Mar 19, 2026

Uh oh!

Copilot AI commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

nbulaj commented Apr 24, 2026

Uh oh!

Copilot AI commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

github-actions Bot Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Mar 17, 2026 •

edited

Loading

Copilot AI commented Mar 19, 2026 •

edited

Loading

Copilot AI commented Apr 24, 2026 •

edited

Loading