[stable33] fix: use the approver's own identity when signing an identification document - #8390
Merged
Merged
Conversation
…ocument fix: use the approver's own identity when signing an identification document When an approver opened an identification document uploaded by an external signer, three steps disagreed about whose identity was being used, while the signing step (getOrCreateApproverSignRequest()) already signed with the approver's account: - SettingsLoader::loadApproverSignatureMethods() exposed the signature methods of the sign request stored in the id docs row, i.e. the uploader's methods — for an external signer, an emailToken bound to their masked email address. - The verification code endpoint only knew signer uuids, so the file uuid the approver route carries answered "Invalid data to sign file". - ModalVerificationCode.requestCode() looked for a signer with me: true, which an approver never is, and failed locally with "Document not found". Make the whole flow use the same rule as signing: - IdentifyMethodService::getSignMethodsOfAccount() builds the account identify method of a user in memory and returns its enabled signature methods; SettingsLoader uses it for the approver. Nothing is persisted: viewing the document does not create the approver's sign request. - SignFileController::requestCodeBySignerUuid() accepts the same idDocApproval=true context as sign(): the uuid is resolved as the identification document (already authorized by the middleware) and the approver's sign request is created or reused before the code is sent. - The frontend takes one route/context decision for signing and for requesting the code (isIdDocApprovalContext(), used by buildSignUrl() and the new buildRequestCodeUrl()); the modal uses getSigningRouteUuid() like Sign.vue does. Tests use different identities for the uploader (external@example.com, emailToken) and the approver (account "approver") and assert that the uploader's methods and sign request never reach the approver flow. Resolves: #8365 Assisted-by: Claude Code:claude-opus-5 Signed-off-by: André Maia <andrefnkmm@gmail.com> [skip ci]
Signed-off-by: Vitor Mattos <vitor@php.rio>
Signed-off-by: Vitor Mattos <vitor@php.rio>
vitormattos
marked this pull request as ready for review
September 13, 2026 21:10
vitormattos
approved these changes
Sep 13, 2026
Signed-off-by: Vitor Mattos <vitor@php.rio>
vitormattos
force-pushed
the
backport/8381/stable33
branch
from
September 13, 2026 22:05
4759447 to
48ff443
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #8381
Warning, This backport's changes differ from the original and might be incomplete⚠️
Todo
Learn more about backports at https://docs.nextcloud.com/server/stable/go.php?to=developer-backports.