- Spegnimento
- 26 agosto 2026 alle ore 05:17 UTC
- Autore
- Kamo
- Impegno
- 6a6662a
Ogni punto finale che ha accettato un VIEW OWN * come un OR-alternativo ha caricato il suo record da sola chiave primaria, mai controllare chi apparteneva a: getSubscription, getSubscriptionOrder, getSubscriptionEvents, getInvoice, getSubscription Accordo e ottenereSubscriptionAgreementHtml. orgId è stato letto per il 401 e mai usato Ancora. Un chiamante che detiene solo il diritto del cliente potrebbe leggere qualsiasi abbonamento, ordine, fattura o accordo sulla piattaforma data il suo UUID. Endpoint che accettano solo il VIEW OWN * (getMySubscriptions, getMySubscriptionOrders, getMyInvoices, getMyAgreements) già derivato membroId dalla sessione e sono stati lasciati intatti. accetta già passa membroId al servizio ed è stato lasciato intatto per la stessa ragione, anche se il servizio stesso non verifica l'accettatore possiede il sottostante abbonamento -- quel gap vive in SottoscrizioneServizio, fuori da questo file raggiungere, ed è annotato per follow-up piuttosto che fisso qui. AbbonamentoRecordDTO, SubscriptionOrderDTO e AbbonamentoInvoiceDTO esporre clienteMemberId direttamente, quindi quei quattro endpoint filtrano dopo il fetch da comparandolo al membro della sessione del chiamanteId. AbbonamentoAgreementDTO espone né un membro né un campo diretto proprietario -- solo l'organizzazioneId e l'aiuto di l'abbonamento appartiene a -- così i due punti di fine accordo risolvono proprietà caricando tale abbonamento e controllando il suo clienteMemberId Invece. 404, non 403, su un errore di proprietà: un 403 confermerebbe ai nomi UUID un record reale in un altro inquilino, che è di per sé una divulgazione. Nominato come contro-esempio nel design del programma invariante 6.