- Rework RsAuthComponent into a card that shows the app, its device, an
access summary and the permission status
- Group connected apps by app and device, so repeated authorizations for
the same app and device (e.g. after a browser update) are shown together,
each with its own revoke action
- Add RsAuthDetailsModalComponent with the full scope list, device,
connected tokens and permission expiry, plus Launch and Revoke actions
(built on the existing ModalComponent)
- Add RemoteStorageAuthorization#device_name (parsed from the user agent)
and #expired?
Part of #254
Add an explicit spec for the storage-first handoff (remoteStorage spec
section 11): launching an app passes only `#remotestorage=<address>`,
never an access token. The app then runs the application-first
(now PKCE-capable) flow itself.
Part of #254
- Add user_agent to remote_storage_authorizations and rs_authorization_codes
- Capture the browser's user agent at consent, carry it on the authorization
code, and store it on the authorization when the code is exchanged
- Store it directly for the implicit flow too
With the reuse shortcut gone, each authorization is already a distinct
per-device token; this adds the metadata needed to label and display them.
Part of #254
The code is redeemed by the client immediately in the OAuth callback, so
a 60-second window is plenty (and matches common practice; RFC 6749 caps
authorization codes at 10 minutes).
Part of #254
Implements the optional OAuth 2.0 Authorization Code grant with PKCE
(RFC 7636) for remoteStorage, as described in the remoteStorage spec
(section 10.1).
- Advertise the authorization and token endpoints plus the supported
code_challenge method (S256) in WebFinger, and bump the advertised
spec version to draft-dejong-remotestorage-27
- Add RsAuthorizationCode: a short-lived (5 min), single-use authorization
code stored only as a SHA256 digest
- Add RsOauthManager services for issuing and exchanging codes, including
S256 verification
- Add a cross-origin POST /rs/oauth/token endpoint that exchanges a code
(and code_verifier) for an access token, with CORS and no CSRF token
- Consent dialog now carries response_type / code_challenge through the
form and redirects with the code in the query string for the code flow
- Remove the existing-token reuse shortcut so every authorization results
in a distinct authorization (and token)
Part of #254
MinIO no longer publishes prebuilt community images (quay.io returns
401, Docker Hub 404), so the dev setup cannot pull the image.
Use a single-node Garage instance instead, which auto-creates the
remotestorage bucket and a dev-key1 access key on first start, and
point liquor-cabinet at it.
The documented flow started web (with Solid Queue in Puma) before the
databases existed, and required manually creating the 389ds back-end
and seeding the LDAP directory and databases. Automate it:
- add an ldap-init one-shot service that creates the 389ds back-end if
it does not exist
- add a web entrypoint that seeds LDAP and the databases on first start,
and runs db:prepare on later boots
- update README and AGENTS accordingly, including the reset steps
db/seeds.rb still required "sidekiq/testing" and wrapped seeding in
Sidekiq::Testing.inline!, but Sidekiq is no longer in the bundle after
the Solid Queue migration, so `rails db:setup` failed with a LoadError.
Run the jobs triggered while seeding inline via Active Job instead,
restoring the previous behavior with the adapter the app actually uses.
"stores a token in redis" asserted an exact count of Redis keys for the
user, but database cleanup only covers SQL and Redis keys accumulate
across examples and spec files. It also relied on a previously-run
example having created the authorization, so it failed depending on test
order and leftover state.
Clear the authorizations:* namespace before each example in the #create
group, create the authorization under test, and assert on its specific
token key instead of a global count.
The admin "Default services" setting writes the LDAP serviceEnabled
attribute, but remoteStorage access was also gated behind an unused
per-user Flipper flag that nothing ever enabled, so remoteStorage was
inaccessible for everyone.
Gate remoteStorage on service_enabled? like the other services, and make
the admin toggle reflect the LDAP attribute (this also fixes it reading
current_user instead of the user being viewed). E-Mail keeps its Flipper
gate for now.
Wire Users::DeviseController as Devise parent controller with the
Turbo-aware responder, so failed form submissions (login, password
reset) render correctly as HTML with 422 status instead of
unprocessable turbo-stream content that Turbo silently drops.
Also fixes a NameError in the responder (rendering_options ->
error_rendering_options) and removes the dead TurboController.
raucao
greg