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

Allow users to save a default signing request expiration

Aperta
  • Qualcosa non va?
#8,718 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
authorization, backend, frontend, full-stack

Direzione di ricerca

Start with the listed Preferences.vue, personalPreferenceVisibility.ts, policies.ts, PolicyService.php, DefaultPolicyResolver.php, and ExpirationRulesPolicy.php files, then inspect existing preference patterns and related tests. Verify the allowed personal default flow, fail-closed behavior, request freeze point, reset behavior, and user isolation; done means all listed tests pass without affecting certificate validity or renewal interval.

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

Descrizione

backend feature-request frontend javascript php

Goal

Let a requester save a personal default for future signing request expiration.

This feature is optional and is available only when policy allows personal defaults.

It must not change requests that already exist.

User flow

When the user can save a personal default, show an explicit option such as:

Signing request expiration

Expires after
[ 3 ] [ days ]

[ ] Use this as my default request expiration

Changing the current request value must not change the personal default unless the user clearly asks to save it.

The same default must also be visible and editable in LibreSign Preferences.

Policy behavior

This feature applies only to maximum_validity.

It does not apply to:

  • signer certificate validity (expiry_in_days);
  • access renewal (renewal_interval).

Use the existing policy preference system:

  • supportsUserPreference;
  • canSaveAsUserDefault;
  • user preference API/store methods;
  • Preferences page;
  • reset to inherited value.

Request override and personal default are separate permissions. Do not enable one only because the other is enabled.

Backend rules

The backend is the source of truth.

When saving a preference, it must validate:

  • the authenticated user;
  • the policy key;
  • the submitted value;
  • that personal defaults are allowed in the current policy context.

A crafted request must not save a preference when a higher-level policy blocks it.

Do not trust frontend visibility as authorization.

Do not allow one user to read or write another user's personal expiration default through this flow.

Request creation

For a new request:

  1. resolve the normal policy hierarchy, including the user's saved default when allowed;
  2. use the resolved value as the initial expiration;
  3. allow a request-only change only when request override is allowed;
  4. persist the final server-resolved value at the request freeze point.

A later change to the personal default must not change an existing request.

Preferences

If a higher-level policy later blocks a saved preference, use the existing clear/block behavior.

If policy data is missing or failed to load, do not show an editable personal-default control.

Main files to inspect

src/views/Preferences/Preferences.vue
src/views/Preferences/personalPreferenceVisibility.ts
src/store/policies.ts
lib/Service/Policy/PolicyService.php
lib/Service/Policy/Runtime/DefaultPolicyResolver.php
lib/Service/Policy/Provider/ExpirationRules/ExpirationRulesPolicy.php

Reuse existing preference patterns. Do not add a separate user-config store for this value.

Target branch

main

Milestone: Next Major (36)

Tests

Cover:

  • preference shown only when allowed;
  • missing policy state fails closed;
  • save uses the existing user preference API;
  • crafted save is rejected when policy blocks personal defaults;
  • reset returns to the inherited value;
  • saved default becomes the initial value for a new request;
  • a request-only change does not update the default;
  • a later default change does not update old requests;
  • one user cannot change another user's preference;
  • certificate validity and renewal interval never appear as personal defaults.

Done when

  • Personal default saving is explicit.
  • Backend policy decides whether it is allowed.
  • Preferences can show, change, and reset the value.
  • New requests use the resolved personal default.
  • Existing requests stay unchanged.
  • 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
7h 38m
PR unite (30g)
490

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.