Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Allow requesters to set signing request expiration

Aperta
  • Qualcosa non va?
#8,717 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript, php
Ambito
backend, frontend, full-stack, testing-qa

Direzione di ricerca

Start by tracing the request flow through src/components/RightSidebar/RequestSignatureTab.vue, src/store/policies.ts, lib/Service/RequestSignatureWorkflowService.php, and the listed policy services. Compare existing signature-flow and footer overrides, then run the relevant request-signature tests. Done means policy-gated editing, server-side resolution and validation, frozen values, and coverage for the listed rejection cases.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

backend feature-request frontend javascript php

Goal

Allow the requester to choose how long a document can still be signed.

This applies only to signing request expiration (maximum_validity).

Signer certificate validity (expiry_in_days) stays under administrator control.

User flow

When the resolved policy allows a request override, show a simple expiration control while the request is still editable.

Example:

Signing request expiration

Set an expiration
[ enabled ]

Expires after
[ 3 ] [ days ]

Use the same duration model as the admin expiration editor.

The initial value comes from the effective policy.

If policy does not allow a request override, do not show an editable control.

If policy data is missing or failed to load, fail closed: do not allow editing.

Backend rules

Use the existing policy override flow. Do not create another settings channel.

The backend must:

  • identify the authenticated requester;
  • validate that the requester may create/update the signing request;
  • validate maximum_validity through the policy definition;
  • check that a request override is allowed;
  • validate the active group context on the server;
  • resolve the final value on the server before it is persisted.

Do not trust canUseAsRequestOverride from the client.

Do not trust a client-provided snapshot or source scope.

Do not use supportsUserPreference only as a shortcut to enable request overrides. Request override and personal default are separate permissions.

Value rules

Use integer seconds in the API.

The frontend can show seconds, minutes, hours, or days, but it must send an exact integer value.

Invalid, negative, non-finite, or unsafe values must be rejected and must not silently become 0.

Whether 0 (no expiration) is allowed for a requester must come from the policy contract. Do not hard-code a frontend bypass.

Lifecycle

The requester may change the value only before the request-scoped expiration reaches its defined freeze point.

After that point, later PATCH requests must not change the frozen expiration.

The stored value must be the backend-resolved effective value.

Scope

Do not expose:

  • expiry_in_days;
  • renewal_interval;
  • personal default saving.

Do not add per-signer expiration controls. The requester sets the expiration for the signing request/document flow.

Main files to inspect

src/components/RightSidebar/RequestSignatureTab.vue
src/store/policies.ts
src/views/Settings/PolicyWorkbench/settings/expiration-rules/model.ts
lib/Service/RequestSignatureWorkflowService.php
lib/Service/RequestSignatureService.php
lib/Service/Policy/PolicyService.php
lib/Service/Policy/Runtime/PolicyContextFactory.php

Reuse existing request override patterns such as signature flow and footer. Do not copy their UI blindly.

Target branch

main

Milestone: Next Major (36)

Tests

Cover:

  • editable control only when backend policy allows it;
  • missing policy state fails closed;
  • effective policy value is the initial value;
  • exact duration conversion;
  • allowed override reaches the backend and is resolved;
  • locked policy rejects a crafted override payload;
  • unauthorized active group context is rejected;
  • invalid and unsafe values are rejected;
  • a frozen value cannot be changed later;
  • certificate validity and renewal interval are never sent as requester overrides.

Add one focused Playwright flow if the existing request-signature helpers can support it without duplicated setup.

Done when

  • A requester can set request expiration only when allowed.
  • Backend authorization is always enforced.
  • The final stored value is server-resolved.
  • Frozen requests cannot be changed.
  • Certificate validity remains admin-controlled.
  • Tests pass.
Additional context
  • If you have questions, feel free to ask in this issue.
  • Give a ⭐️ star to this repository if you find LibreSign useful and would like to support the project.
  • You can also join our community: https://t.me/LibreSign
Lingua principale
PHP
Stelle
818
Fork
146
Merge medio
8h 6m
PR unite (30g)
500

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di LibreSign/libresign

Tutte le issue di LibreSign/libresign

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.