Tree: dbeec752b8

cached-config-operations

main

revert-7033-patch-1

test_dylint

v2-registration

0.10.0

0.11.0

0.12.0

0.13.0

0.9.0

1.0.0

1.1.0

1.10.0

1.11.0

1.12.0

1.13.0

1.13.1

1.14

1.14.1

1.14.2

1.15.0

1.15.1

1.16.0

1.16.1

1.16.2

1.16.3

1.17.0

1.18.0

1.19.0

1.2.0

1.20.0

1.21.0

1.22.0

1.22.1

1.22.2

1.23.0

1.23.1

1.24.0

1.25.0

1.25.1

1.25.2

1.26.0

1.27.0

1.28.0

1.28.1

1.29.0

1.29.1

1.29.2

1.3.0

1.30.0

1.30.1

1.30.2

1.30.3

1.30.4

1.30.5

1.31.0

1.32.0

1.32.1

1.32.2

1.32.3

1.32.4

1.32.5

1.32.6

1.32.7

1.33.0

1.33.1

1.33.2

1.34.0

1.34.1

1.34.2

1.34.3

1.35.0

1.35.1

1.35.2

1.35.3

1.35.4

1.35.5

1.35.6

1.35.7

1.35.8

1.36.0

1.37.0

1.37.1

1.4.0

1.5.0

1.6.0

1.6.1

1.7.0

1.8.0

1.9.0

1.9.1

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from 'dbeec752b8'

${ noResults }

Commit Graph

1 Commits (dbeec752b86a2ffd18a235c7c7d971cb094e0eee)

Author	SHA1	Message	Date
tom27052006	dbeec752b8	Add device approval by an organization administrator Completes the trusted device flow for the case it was missing: a member who unlocks with a trusted device, has no other device of their own left to ask, and therefore has no way back into their vault. They can now turn to the administrators of their organization, who hand them their own user key encrypted for the key pair of the asking device. New `atype` on auth_requests, mirroring bitwarden/server's AuthRequestType. It decides who may answer a request and how long it stays open: 15 minutes between the user's own devices, a week for an administrator, and half a day for their answer once given. The purge job applies that per type instead of dropping everything after 15 minutes, and both the answer and the anonymous lookup now refuse an expired request, which they did not before. POST /auth-requests/admin-request ask, one request per org GET /organizations/<id>/auth-requests what is waiting for an answer POST /organizations/<id>/auth-requests/<id> approve or deny one POST /organizations/<id>/auth-requests/deny deny several POST /organizations/<id>/auth-requests answer several Asking requires authentication, so the anonymous `POST /auth-requests` now refuses the type. Answering goes through the organization the request was addressed to and needs admin rights there; the asking user cannot answer their own request through `PUT /auth-requests/<id>`, which would make the whole detour pointless. A denial is saved but not announced, so a request that did not come from the member does not learn that it was seen. The administrator's view leaves out the access code, which is the asking device's proof and none of their business. The administrators are mailed when a request arrives, the member when one of their devices was let in, so an approval nobody asked for does not pass unnoticed. Two fixes without which none of this is reachable from a client: - `UserDecryptionOptions.TrustedDeviceOption` reported `HasAdminApproval` and `HasManageResetPasswordPermission` as a flat false. The clients decide on `hasAdminApproval || hasMasterPassword` whether a login is a returning user or a brand new one, so a member without a master password was shown the screen for creating an account, on every device but the one they first trusted. Both are now derived from the account recovery enrollment and the role. - `PUT /organizations/<id>/users/<id>/reset-password-enrollment` demanded a master password whenever a key was supplied. An account that unlocks with a trusted device has none, and the clients send nothing but the key when they enroll during registration, so enrolling was impossible for exactly the accounts that need it most. Upstream carves out the same exception, keyed on the organization's SSO configuration rather than on a server-wide setting as here. Enrolling now also accepts a pending invitation, as upstream does, so a just-provisioned member does not stay invited forever with nobody able to confirm them.	2 weeks ago