doorkeeper-gem/doorkeeper

This system is the Doorkeeper gem, a comprehensive OAuth 2.0 authorization server library for Ruby applications. It provides the core infrastructure for managing client applications, issuing and validating access tokens, and handling various OAuth grant flows such as Authorization Code and Client Credentials. The system includes a configurable web interface for managing authorized applications and revoking access, alongside robust support for modern security standards like PKCE, private key JWT authentication, and token introspection.

30 changes.

This period centered on the major v6.0.0 release, which refactored the core architecture into a modular, strategy-based system to support modern OAuth 2.0 standards like PKCE, token introspection, and private key JWT. The work included implementing new controllers, redesigned UI views, and comprehensive generator tooling, all supported by a new dummy Rails application and extensive test infrastructure to ensure integration stability.

25 changes.

This period focused on refactoring the core OAuth logic into modular, class-based structures to support RFC 8707 resource indicators and align with OAuth 2.1 security recommendations. The work included extensive test coverage for authorization flows, helper modules, and model concerns, alongside a significant upgrade to Bootstrap 4 for the admin interface.

24 changes.

This period focused on expanding framework support with a new Grape integration module and modernizing the core authentication system by introducing a registry-based strategy for client credentials and built-in private\_key\_jwt support. Significant architectural refactoring improved Active Record model performance and security, while comprehensive test coverage was added across the new features, configuration validation, and expanded Rails compatibility matrix.

Introduces a new Grape integration module that provides \doorkeeper\_authorize!\ and \doorkeeper\_render\_error\_with\ helpers for Grape applications (version 0.10 and above). The integration includes an \AuthorizationDecorator\ to normalize access token retrieval from various HTTP headers (including \X-HTTP\_AUTHORIZATION\ variants) and implements logic to refuse requests that transmit an access token by more than one method, ensuring consistent and secure authorization behavior within Grape endpoints.

lib/doorkeeper/grape · high confidence

Users can now view a list of their authorized OAuth applications and revoke access. This change introduces the index page displaying application names and creation dates, along with a delete form that allows users to revoke specific application authorizations via a confirmation dialog.

_app/views/doorkeeper/authorized\applications · high confidence

The application now includes specific layout templates for the Doorkeeper OAuth2 engine: \doorkeeper/admin.html.erb\ provides a Bootstrap-styled navigation bar with links to OAuth applications and the home page (conditionally rendered if \root\_path\ is available), while \doorkeeper/application.html.erb\ offers a simpler container layout for standard user-facing OAuth pages. These layouts replace the previous default layout usage, ensuring consistent styling and navigation structure for the authentication provider's interface.

app/views/layouts · high confidence

The repository now includes standard development configuration files to streamline local setup and code quality enforcement. This includes \.rubocop.yml\ and \.rubocop\_todo.yml\ for Ruby linting, \.editorconfig\ for editor consistency, \.gitignore\ and \.dockerignore\ for build artifacts, and configuration for CI/CD and coverage tools (\.codeclimate.yml\, \.coveralls.yml\, \.hound.yml\, \.rspec\). Additionally, \AGENTS.md\ provides a guide for AI agents interacting with the codebase, and \.gitattributes\ configures a union merge driver for \CHANGELOG.md\ to prevent merge conflicts when multiple PRs add changelog entries simultaneously.

(repo-wide) · high confidence

A new Ruby benchmark script has been added to measure the performance of the client credentials grant flow using the Doorkeeper library. The script sets up an in-memory SQLite database, configures Doorkeeper with the necessary grant flows, and uses the benchmark-ips gem to report throughput for token request authorization.

benchmark · high confidence

Doorkeeper now provides dedicated Rails generators to add optional capabilities and configuration to your application without requiring manual migration writing. These include generators for polymorphic resource owners, PKCE support, resource indicators (RFC 8707), confidential applications, and application ownership. Additional generators handle security and compliance behaviors such as revoking tokens on authorization code reuse, revoking refresh tokens after access token use, and preserving granted scopes on refresh tokens during narrowed refreshes. A new install generator sets up the initializer, routes, and locales, while a views generator allows copying default UI templates. A generator also exists to remove the NOT NULL constraint on application secrets for public clients.

lib/generators/doorkeeper · high confidence

A new \bin/console\ script has been added, allowing developers to launch an interactive IRB session pre-configured with the Doorkeeper gem, Rails, and an in-memory SQLite database loaded with the dummy schema. This environment automatically logs Doorkeeper and Rails versions and configures the ORM to Active Record, facilitating easier debugging and experimentation without needing a full application setup.

bin · high confidence

Users can now run \rake doorkeeper:db:cleanup\ to remove stale data from Doorkeeper tables. This task orchestrates four sub-tasks: removing revoked and expired access tokens, and revoked and expired access grants. The cleanup of expired access tokens is specifically limited to those without a refresh token, ensuring that active sessions are not inadvertently cleared while still allowing for the removal of orphaned or expired credentials.

lib/doorkeeper/rake · high confidence

The model implementations in lib/doorkeeper/models have been refactored into standalone mixin modules (AccessGrantMixin, AccessTokenMixin, ApplicationMixin) that encapsulate core OAuth behaviors such as token lookup, secret matching, PKCE support, and scope validation. This change separates the domain logic from specific ORM dependencies, allowing Doorkeeper to support multiple database backends (e.g., ActiveRecord, Mongoid) by providing ORM-specific adapters that include these mixins, rather than embedding database-specific code directly in the models.

lib/doorkeeper/models · high confidence

The request processing logic for OAuth flows (Authorization Code, Client Credentials, Password, Refresh Token, and Pre-authorization) has been restructured into specific strategy classes under \Doorkeeper::Request\. Each flow now has its own class (e.g., \AuthorizationCode\, \Password\) that delegates to the server context and constructs the corresponding \OAuth::Request\ object. This change isolates the logic for each grant type, making the codebase more modular and easier to maintain, while introducing a base \Strategy\ class to standardize initialization and request construction.

lib/doorkeeper/request · high confidence

The Doorkeeper dashboard helper now renders validation errors using Bootstrap 4's 'invalid-feedback' CSS class instead of previous styling, ensuring form error messages display correctly with the updated Bootstrap 4.0 framework. The helper also provides a submit path method that dynamically determines the correct OAuth application path based on whether the application is persisted.

app/helpers · high confidence

The .claude directory now uses symlinks to point CLAUDE.md to ../AGENTS.md and the skills directory to ../.agents/skills. This change allows the Claude tooling to access the project's central agent definitions and skills without duplicating content, ensuring that updates to the main agent configuration are automatically reflected in the Claude environment.

.claude · high confidence

The .cursor/rules file has been added as a symbolic link pointing to the project root's AGENTS.md file, ensuring that Cursor AI configuration is centralized in a single location.

.cursor · high confidence

Doorkeeper 6.0 replaces the legacy \client\_credentials\ configuration with a new \client\_authentication\ registry (RFC 6749 §2.3), allowing developers to explicitly define and order authentication methods like \client\_secret\_basic\ and \private\_key\_jwt\. The authorization and token endpoints are now driven by a new \GrantFlow\ registry, which decouples request handling from hardcoded logic. Security is significantly improved with a new \HttpFetcher\ that prevents Server-Side Request Forgery (SSRF) by validating DNS resolutions against RFC 6890 special-use ranges and pinning connections to vetted addresses. The gem also introduces a thread-safe \DocumentCache\ for JWKS fetching, a new \SecretStoring\ strategy system (supporting BCrypt, SHA256, and plain text), and stricter validation that rejects requests using multiple client authentication methods or multiple access token transmission methods.

lib/doorkeeper · high confidence

This release introduces a complete internal restructuring of the Doorkeeper library, moving from a monolithic model-based approach to a modular, strategy-based architecture. Key changes include the extraction of ORM logic into separate adapters (defaulting to ActiveRecord), the introduction of a new request/response object model for OAuth flows (Authorization Code, Client Credentials, Password, Refresh Token), and support for modern OAuth 2.0 standards such as RFC 7523 (Private Key JWT client authentication), RFC 8414 (OAuth 2.0 Authorization Server Metadata), and RFC 7662 (Token Introspection). The configuration system has been rewritten to support lazy evaluation and granular setup, while deprecated methods like \doorkeeper\_for\ have been removed in favor of new helpers. This is a breaking change that requires users to update their configuration blocks and potentially adjust custom ORM implementations.

lib · high confidence

Doorkeeper now includes a built-in implementation of the private\_key\_jwt client authentication method (RFC 7523), allowing clients to authenticate using JWT assertions signed with asymmetric keys instead of shared secrets. This feature includes configurable JWKS caching and replay protection to prevent assertion reuse. Additionally, the library introduces a structured client authentication registry with dedicated strategies for client\_secret\_basic, client\_secret\_post, and none (public clients). The none strategy has been hardened to strictly reject requests carrying header-based authentication (like Basic auth) unless they are explicitly Bearer-token authorized for the endpoint, preventing public clients from being silently misidentified. The client\_secret\_basic strategy now enforces RFC 7521 §4.2 by requiring the client\_id in the request body to match the identity established by the Basic header, rejecting mismatched credentials.

_lib/doorkeeper/oauth/client\authentication · high confidence

A new \Doorkeeper::Helpers::Controller\ module is introduced to provide shared methods for controllers inheriting from \Doorkeeper::ApplicationMetalController\ or \Doorkeeper::ApplicationController\. This module exposes \current\_resource\_owner\ as a view helper, implements \authenticate\_resource\_owner!\ and \authenticate\_admin!\ using configured blocks, and adds \doorkeeper\_token\ which safely handles multiple access token transmission errors by returning nil instead of raising. It also includes \skip\_authorization?\ to check pre-authorization settings, \enforce\_content\_type\ to reject non-form-urlencoded PUT/PATCH/POST requests, and error handling methods \get\_error\_response\_from\_exception\ and \handle\_token\_exception\ to standardize OAuth error responses.

lib/doorkeeper/helpers · high confidence

The route generation logic has been refactored into a reusable mapping system that allows users to customize which controllers are used, change route name aliases, and skip specific controllers entirely. This change introduces new internal classes (Mapper, Mapping, AbstractRouter, Registry) to handle route definition, enabling extensions to register additional routes and giving application developers finer control over the Doorkeeper routing setup without modifying core code.

lib/doorkeeper/rails/routes · high confidence

The application now includes a dedicated stylesheet for Doorkeeper's authorization and management interfaces. This change introduces a centered, card-style layout with a light gray background, rounded corners, and shadow effects for the main container, ensuring that OAuth permission forms and authorized application lists are displayed with a consistent, modern visual design.

app/assets/stylesheets/doorkeeper · high confidence

The web frontend for managing OAuth applications has been completely rewritten with a modern, responsive layout. Users can now create, edit, and view applications through a structured form that includes validation feedback for fields like name, redirect URI, confidentiality, and scopes. The application detail page provides a clear overview of the client ID, secret (with support for hashed secrets), assigned scopes, and callback URLs, while the index page lists all applications with quick actions to edit or delete them.

app/views/doorkeeper/applications · high confidence

The authorization views have been completely rewritten to support modern OAuth 2.0 flows. Users now see a dedicated consent screen (new.html.erb) that explicitly lists requested scopes and any resource indicators, along with custom access token attributes. The flow now supports the 'form\_post' response mode via a new view (form\_post.html.erb) that automatically submits the authorization response via a hidden form, improving compatibility with certain clients. Additionally, a new error view (error.html.erb) provides clearer error descriptions to users, and the authorization code display (show.html.erb) has been updated with accessibility improvements. These changes enhance security (via PKCE support fields), usability, and compliance with OAuth 2.0 specifications.

app/views/doorkeeper/authorizations · high confidence

The ActiveRecord ORM implementation has been restructured to separate model logic into reusable mixins, with \AccessToken\, \AccessGrant\, and \Application\ now acting as thin wrappers that include these modules. This change also introduces a new \StaleRecordsCleaner\ helper class used by Rake tasks to clean up revoked and expired tokens, ensuring that expiration logic is correctly applied using SQL math when supported. Additionally, the \RedirectUriValidator\ is now explicitly defined within the ActiveRecord ORM directory, enforcing stricter validation rules such as refusing script schemes and handling blank URIs according to configuration.

_lib/doorkeeper/orm/active\record · high confidence

The Active Record model mixins for AccessGrant, AccessToken, Application, and SecretStorable have been rewritten to improve security, performance, and configurability. Secret storage now uses a conditional upgrade strategy that prevents race conditions during secret rotation, and applications support custom secret generators. Access token refresh logic has been optimized to support a 'revoke-on-use' pattern via a new \previous\_refresh\_token\ column, reducing database lock contention. Additionally, strict loading is disabled by default for these models, and serialization now correctly uses \as\_json\ to respect privacy settings and custom application classes.

_lib/doorkeeper/orm/active\record/mixins · high confidence

The ActiveRecord ORM implementation now uses standard Ruby \autoload\ for all model classes (AccessGrant, AccessToken, Application, RedirectUriValidator) and mixins, replacing the previous reliance on \ActiveSupport.on\_load(:active\_record)\. This change ensures that model concerns are included at the correct time during class loading, preventing issues with deferred loading and configuration application, while keeping the \run\_hooks\ method as a no-op for compatibility.

lib/doorkeeper/orm · high confidence

The Client Credentials grant flow has been restructured into dedicated Creator, Issuer, and Validator components. This change introduces configurable token reuse logic, allowing existing valid tokens to be returned instead of issuing new ones, and adds a \revoke\_previous\_client\_credentials\_token\ configuration option to control whether previous tokens are revoked upon reuse. The implementation also ensures that token matching considers custom access token attributes and resource indicators, and validates that the client application explicitly supports the Client Credentials grant flow.

_lib/doorkeeper/oauth/client\credentials · high confidence

The Doorkeeper controllers have been restructured into a clear inheritance hierarchy: \ApplicationController\ serves as the base (handling admin authentication, CSRF protection, and API-mode mime negotiation), while \ApplicationMetalController\ provides a lightweight base for API-only endpoints. \ApplicationsController\ now explicitly forces JSON format in API mode to prevent HTML negotiation failures, and \AuthorizationsController\ introduces pre-authorization client validation and supports form\_post responses. New endpoints include \MetadataController\ for OAuth 2.0 Authorization Server Metadata (RFC 8414), \AuthorizedApplicationsController\ for listing and revoking user-authorised apps, and \TokenInfoController\ for token introspection (RFC 7662). The \TokensController\ now implements RFC 7009 token revocation with strict client ownership checks and supports both access and refresh token revocation via a unified hint-based lookup.

app/controllers · high confidence

The OAuth helper logic has been reorganized into three new dedicated modules: ScopeChecker, UniqueToken, and URIChecker. ScopeChecker now validates scopes against server and application-level configurations, including support for grant-type restrictions. UniqueToken centralizes access token generation, allowing configuration of the generator method and token size. URIChecker implements stricter URI validation, including blocking script schemes (javascript, vbscript, data), enforcing RFC 6749 simple string comparison for redirect URIs, and handling loopback interface variations per RFC 8252.

lib/doorkeeper/oauth/helpers · high confidence

The OAuth request logic in \lib/doorkeeper/oauth\ has been restructured into a class-based hierarchy (e.g., \AuthorizationCodeRequest\, \BaseRequest\) to improve maintainability and consistency across grant types. This change introduces support for RFC 8707 Resource Indicators, allowing access tokens to be restricted to specific resource audiences via the \resource\ parameter. Additionally, the \PreAuthorization\ class now validates client details before resource owner authentication, enabling earlier error responses for invalid clients or redirect URIs without requiring a login. The \OAuth::Client\ class was also updated to use the new client authentication registry, and various response classes (\ErrorResponse\, \CodeResponse\) were refactored to support RFC 9207 issuer identification and improved error handling.

lib/doorkeeper/oauth · high confidence

The authorization logic has been split into separate \Code\ and \Token\ classes to handle the Authorization Code and Implicit grant flows independently. This change introduces a new \Context\ object that provides richer information (client, grant type, scopes, resource owner) to hooks and configuration lambdas, enabling more granular control over token lifetimes via the \custom\_access\_token\_expires\_in\ setting. It also enforces the new \public\_client\_access\_token\_expires\_in\ configuration to cap token lifespans for unauthenticated clients, aligning with OAuth 2.1 security recommendations. Additionally, the \URIBuilder\ class now correctly handles query parameter merging to prevent duplicate parameters in redirect URIs, and both flow classes support persisting and carrying RFC 8707 resource indicators through the authorization process.

lib/doorkeeper/oauth/authorization · high confidence

Doorkeeper now uses a dedicated \Doorkeeper::Rails::Helpers\ module to manage authorization checks and error rendering, restoring the \doorkeeper\_authorize!\ helper and allowing custom rendering options for unauthorized, forbidden, and bad request errors. The routing layer has been restructured into a modular \Doorkeeper::Rails::Routes\ system that explicitly defines endpoints for authorizations, tokens, revocation, introspection, token info, applications, and OAuth 2.0 Authorization Server Metadata, with introspection routes conditionally disabled based on configuration.

lib/doorkeeper/rails · high confidence

Client authentication has been restructured from a flat, deprecated callable-based approach into a modular registry system. This introduces a new \ClientAuthentication::Registry\ that allows registering and looking up authentication strategies by name, supporting both new built-in strategies (such as \private\_key\_jwt\) and legacy custom extractors via an adapter. The change ensures backward compatibility by wrapping legacy callables in a \LegacyCallable\ adapter that mimics the previous 'first match wins' behavior, while also introducing a \FallbackMethod\ to handle unauthenticated requests gracefully. Users benefit from a more extensible and secure authentication flow that aligns with RFC 6749 and RFC 7523, allowing for custom strategies to be registered without modifying core logic.

_lib/doorkeeper/client\authentication · high confidence

The configuration system has been refactored to use a reusable DSL (AbstractBuilder and Option module), allowing extensions to define their own config options. Additionally, the gem now performs comprehensive validation at boot time, issuing warnings or errors for misconfigurations such as unknown client authentication methods, missing issuer identity for private\_key\_jwt, invalid PKCE methods, and the use of deprecated grant flows or secret fallback strategies.

lib/doorkeeper/config · high confidence

The model logic in \lib/doorkeeper/models/concerns\ has been reorganized into distinct concerns (such as \Accessible\, \Expirable\, \Revocable\, and \SecretStorable\) to improve code clarity and maintainability. A new \WriteToPrimary\ concern was introduced to ensure that write operations are routed to the primary database when using Rails read replicas, preventing data consistency issues during implicit grant flows. Additionally, the \SecretStorable\ concern now supports a fallback strategy for upgrading token secrets, and the \Reusable\ concern implements a configurable token reuse limit.

lib/doorkeeper/models/concerns · high confidence

The Doorkeeper admin interface now uses a dedicated stylesheet to manage its layout independently from the user-facing views. This change introduces a specific rule to constrain the width of error fields within form groups to 16.66667%, ensuring consistent styling for validation messages in the admin section.

app/assets/stylesheets/doorkeeper/admin · high confidence

The system now allows expired refresh tokens to be explicitly revoked. This is implemented by introducing dedicated wrapper classes for access and refresh tokens within the \RevocableTokens\ module; specifically, the new \RevocableRefreshToken\ class defines revocability based on whether the underlying token is already revoked, enabling the revocation workflow to proceed even for tokens that have passed their expiration date.

_lib/doorkeeper/revocable\tokens · high confidence

The generator templates for Doorkeeper have been updated to support new database schema features and configuration options. New migration templates have been added to enable polymorphic resource owners (allowing applications to be owned by different model types), PKCE (Proof Key for Code Exchange) support via code challenge columns, resource indicators, and the tracking of previous refresh tokens and refresh token scopes. The main migration template now includes a \confidential\ boolean column for applications and an index on \access\_token\_id\ in the access grants table to support authorization code reuse revocation. Additionally, the initializer template has been refreshed with documentation and configuration options for multiple database roles, public client token expiration limits, token reuse settings, and custom access token expiration logic.

lib/generators/doorkeeper/templates · high confidence

The vendorized Bootstrap CSS has been updated to version 4.0.0. This change brings modern CSS features such as CSS custom properties (variables), a new flexbox-based grid system, and updated component styles for forms, buttons, and tables, which may alter the visual appearance and layout of the application's UI.

vendor · high confidence

Add ActiveRecord ORM support for test suite; Add dummy Rails application initializer templates for testing; Add dummy app schema.rb for test database setup; Add test environment configuration for the dummy application; Added FactoryBot support file; Added RSpec support helpers for configuration inspection and view rendering assertions; Added User model for dummy application testing; Added comprehensive test coverage for OAuth request and response classes; Added controller specs for Doorkeeper components; Added dummy Rails application for testing; Added dummy application controllers for testing OAuth integration; Added dummy application views for testing; Added integration tests for Grape API support; Added integration tests for protected resource access and token validation; Added model specs for AccessGrant, AccessToken, Application, and PolymorphicResourceOwner; Added request specs for OAuth endpoints; Added request specs for applications and authorized applications endpoints; Added routing specs for custom controllers, scoped routes, and defaults; Added shared test contexts and examples for token and hashing specs; Added test coverage for OAuth authorization flows and URI handling; Added test coverage for OAuth client authentication strategies; Added test coverage for OAuth helper modules; Added test coverage for OAuth hooks context and Rails router components; Added test coverage for Sprockets 4 asset compilation; Added test coverage for core library components; Added test coverage for grant flow registration and matching logic; Added test coverage for model concerns; Added test coverage for redirect URI validation, server strategy handling, stale record cleaning, and version reporting; Added test coverage for the Client Credentials flow components; Added test fixture for generated routes file; Added test helper for user session management; Added test infrastructure with factories and coverage tracking; Added tests for ActiveRecord ORM integration and rake tasks; Added tests for Doorkeeper dashboard helper error rendering; Added tests for Doorkeeper generator specs; Added tests for database role support and SQL expiration math; Added unit tests for the Strategy base class; Comprehensive request specs for OAuth grant flows and authentication methods; New test helper modules for OAuth flows and configuration; Updated dummy app database schema for testing.

The gemfile configuration has been updated to include dedicated Appraisal files for Rails versions 7.0, 7.1, 7.2, 8.0, 8.1, and the Rails edge branch, significantly broadening the supported test matrix. This change ensures compatibility testing across these specific Rails releases, with Rails 8.0 and 8.1 configurations also pinning the sqlite3 gem to version 2.3 and constraining the json gem to below version 3.0 to address Active Support compatibility issues.

gemfiles · high confidence

The gem now requires Ruby 3.2 or higher and supports Rails versions from 7.0 up to (but not including) 8.2. Development tooling has been updated to use RSpec 8, Rubocop 1.72 with its associated linter extensions, FactoryBot 6, Database Cleaner 2, and the modern Ruby 'debug' gem, while pinning the 'json' gem below version 3 to maintain compatibility with Active Support's JSON handling.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 50 → 67 (+16.6)
• Rubric changed (rubric-2026.08.15 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 99 (-1.0)
• Architecture 96 → 90 (-5.4)
• Maturity 59 → 62 (+2.6)
• Readiness 30 → 69 (+38.8)
• Security 62 → 78 (+16.7)
• Domain Modelling 100 (new)
• Accessibility 64 (new)

• Coverage not measured — test suite did not build
• Dimension evaluation failed
• Disclosure policy has no reporting contact
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Low IaC: DS-0026 (Dockerfile)
• Medium: security finding (details withheld)
• No exposed public API
• No tests found
• Test reliability not included

• Confusingly similar method names with potentially overlapping intent. 'client_authentication' and 'client_authentication_methods' differ only by an 's' suffix, which in Ruby often implies a collection vs a single item, but here both likely return collections or configurations of methods. 'client_credentials_methods' is distinct but closely related, leading to cognitive load when determining which config accessor retrieves the active authentication strategy.
• Duplicated block (8 lines × 2) (lib/doorkeeper/models/access_grant_mixin.rb)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Inconsistent naming convention for boolean configuration accessors. 'reuse_access_token' is a Property (getter), while 'reuse_access_token?' is a Method. In Ruby, boolean getters are typically methods ending in '?'. Having both a property and a method with the same base name and boolean intent is redundant and confusing.
• Medium IaC: WD-DOCKER-0003 (Dockerfile)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• No SBOM
• …and 10 more

• 85 commits — 75 feature/other, 10 fixes

• (repo) — 35 commits
• (root) — 26 commits
• lib/doorkeeper — 12 commits
• spec/lib — 5 commits
• .github/workflows — 4 commits
• .agents/skills — 1 commit
• spec/controllers — 1 commit
• spec/spec_helper.rb — 1 commit

• fix: Merge branch 'main' into fix/exclude-vendor-bundle-from-gem
• fix: Merge pull request #1907 from 55728/fix/resource-indicators-without-migration
• fix: Merge pull request #1913 from doorkeeper-gem/fix-require-spec_helper
• fix: Merge pull request #1918 from 55728/fix/api-only-spec-coverage-reset
• fix: Merge pull request #1923 from 55728/fix/fallback-secret-upgrade-hooks
• fix: Merge pull request #1926 from doorkeeper-gem/fix/private-key-jwt-audience-host-fallback
• fix: Merge pull request #1938 from luizkowalski/fix/1937-parse-error-in-token-extraction
• fix: Merge pull request #1951 from eglitobias/fix/exclude-vendor-bundle-from-gem
• fix: Merge pull request #1953 from doorkeeper-gem/fix/custom-expires-in-followups
• fix: One more changelog fix
• change: Add CI job for Trusted Publishers
• change: Add missed steps for Coveralls
• change: Add missed variables for Coveralls
• change: Add public_client_access_token_expires_in configuration option
• change: Add the #1938 changelog entry
• change: Answer server_error instead of raising when the resource column is missing
• change: Attempt to connect to other IP addresses if the first one fails
• change: Build the private_key_jwt audience only from the server's own identity
• change: Clarify that fallback: :plain is a migration-period setting
• change: Consult custom_access_token_expires_in in the refresh_token grant
• …and 65 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

doorkeeper-gem/doorkeeper was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.