Tags give the ability to mark specific points in history as being important
-
1.0.3
02dd2ff9 · ·1.0.3 — a quick start that was actually run, and a log that says why Documentation and diagnostics. No behavior change in the endpoints, no configuration change, no breaking change. Both changes come from the same exercise: installing the published 1.0.2 from drupal.org into a fresh Drupal 11 site and following the README as a newcomer would, rather than as its author. - The README leads with a six-step quick start, each step executed on that site before being written down, with the real request and response bodies. The previous instruction hid the only step that takes work — creating the signing key means two forms in two other modules — behind a sentence that sounded like there was none. Two behaviors newcomers reasonably mistake for bugs are now stated up front: a default logout leaves the access token valid until it expires, and five failed logins lock an account for six hours. - The log entry explaining why a token could not be issued was written inside the transaction that the failure then rolls back, so it was discarded with it. The only surviving entry named no cause, and the HTTP response is deliberately a bare 500, so there was nowhere left to look. The reason is now logged after the rollback. Verified on Drupal 10.6.10 / PHP 8.2 and Drupal 11.4.5 / PHP 8.4.1: 56 tests, PHPCS clean against Drupal and DrupalPractice, PHPStan level 6 as a blocking gate, and all thirteen jobs green on drupal.org pipeline 933450.
-
1.0.2
a88b7c93 · ·1.0.2 — a keyless login no longer fails a login that succeeded One fix, no configuration change and no breaking change. - UserLoginInterceptSubscriber called JwtAuth::generateToken() unguarded, so on a site with no usable signing key POST /user/login?_format=json answered 500 — after core had already authenticated the account. The client saw a failure for a login that had in fact succeeded. The response is now left exactly as core built it and the failure is logged, which is what the same call site in TokenController has been doing all along. - The FALSE checks around both calls were dead code. generateToken() is documented "@return string|bool ... False if there is a problem encoding" but returns the transcoder's ?string, so a missing key yields NULL. Both sites now reject any non-string, which keeps the typed 500 internal_error on /auth/token correct once the upstream fatal is fixed and NULL starts coming back. The root cause is upstream: drupal/jwt raises an Error from inside its transcoder when no key is configured. Reproduced, reviewed and patched on https://www.drupal.org/project/jwt/issues/3409096 — this release is correct whether or not that lands. Verified on Drupal 10.6.10 / PHP 8.2 and Drupal 11.4.5 / PHP 8.4.1: 56 tests, PHPCS clean against Drupal and DrupalPractice, PHPStan level 6 as a blocking gate, and all thirteen jobs green on drupal.org pipeline 933436.
-
1.0.1
17e5c921 · ·1.0.1 — API contract and a missing-key warning Two fixes, both found by installing the published 1.0.0 from drupal.org into a fresh Drupal 11 site and exercising every endpoint. - POST /auth/token/revoke answered an HTML access-denied page when no Authorization header was presented, breaking the promise that every error is a JSON envelope with a stable code. It now returns 401 invalid_token with WWW-Authenticate: Bearer. - A missing JWT signing key is reported on the status report. Previously the first symptom was a 500 raised inside drupal/jwt on any Bearer request. Verified on Drupal 10.6.10 / PHP 8.2 and Drupal 11.4.5 / PHP 8.4.1: 53 tests, PHPCS clean against Drupal and DrupalPractice, PHPStan level 6 as a blocking gate, and all thirteen jobs green on the drupal.org pipeline.
-
1.0.0
ae772b3b · ·1.0.0 — initial public release JWT login, refresh token rotation with OWASP reuse detection, and optional server-side revocation for immediate logout, for decoupled Drupal. Verified on Drupal 10.6.10 / PHP 8.2 and Drupal 11.4.5 / PHP 8.4.1, and by the drupal.org pipeline on the current core, the previous major and the maximum supported PHP: 50 tests, PHPCS clean against Drupal and DrupalPractice, PHPStan level 6 as a blocking gate.