- Spegnimento
- 23 settembre 2026 alle ore 12:42 UTC
- Autore
- Kamo
- Impegno
- 19505fa
Ogni gestore di get/update/delete-by-uid al dettaglio di CommerceMarketController sub-resources (categorie, marchi, attributi/valori, immagini, varianti, tag, recensioni, clienti, clienti, classi fiscali/zone/tasse, sconti, prezzo liste / entrate, carte regalo, posizioni, livelli di stock/regolamenti, spedizione zone/metodo, vettori, spedizioni, carrelli/cart articoli, bozza ordini, ordine note) ha risolto la riga attraverso un nudo findById(uid)/deleteById(uid), senza controllare che la fila appartenesse all'organizzazione del chiamante. Qualsiasi autenticata membro di qualsiasi org potrebbe leggere, modificare o eliminare le righe di un'altra organizzazione indovinare o enumerare un uid - per i clienti (sequential Long ids) questo era una perdita PII di nome, e-mail e spendere; per carte regalo, livelli di stock e carrello totale era l'accesso di scrittura a soldi di un altro inquilino e cifre di inventario. ottenereMarketVendors aveva lo stesso gap: i suoi fratelli POST/PUT/DELETE già risolto il mercato tramite findByIdAndOrganizationId, ma il GET non lo ha fatto. Risolto da filettatura orgId in ogni di queste ricerche: - Le entità con la loro colonna di organizzazione (la maggior parte di loro) ora risolvono attraverso un nuovo metodo di repository findByUidAndOrganizationId, che rispecchia il C'e' qualcosa che non va. modello (una @Query esplicita, dal momento che questi enti' campo id è `uid`, non `id`). - Entità senza colonna di organizzazione propria (immagini di prodotto/varianti tramite il loro prodotto, valori di attributo tramite il loro attributo, articoli di carrello tramite il loro carrello, le voci del listino tramite il loro listino dei prezzi) sono oggetto di un No, no, no. query che si unisce all'org del genitore. - Una manciata di chiavi straniere create-time prese verbatim dal corpo di richiesta (un mercato id, una categoria di genitori id, un cliente tier id, una zona fiscale / classe, un cross-link immagine/variante, un vettore/localizzazione della spedizione, un progetto l'indirizzo salvato dell'ordine) ha ottenuto lo stesso lookup org-scoped, chiudendo lo stesso classe di gap a tempo di scrittura, non solo al by-id lettura / aggiornamento / cancellazione. - lookupMarket e il nuovo lookupOffering(id, orgId) sovraccarico centralise questo per ogni crea handler che in precedenza li ha chiamati unscoped. - getMarketVendors ora risolve il suo mercato tramite findBy Id andOrganizationId prima di elencare i venditori, abbinando i propri fratelli. In ogni caso una riga straniera-org ora risponde esattamente come una mancante: stessa eccezione, stesso messaggio, stessa risposta HTTP il gestore già prodotto per un cattivo uid - nessuna nuova informazione è trapelata dalla correzione stessa. Assegnazione di massa: updateGiftCard non accetta più correnteBalance da richiesta corpo. Nessuna RoleRightType esistente (MANAGE PRICING, MANAGE ORDERS, ...) si riferisce chiaramente alla regolazione manuale dell'equilibrio, quindi per la posizione del coordinatore istruzioni che non abbiamo inventato uno; un membro dello stesso-org può ancora modificare La carta e' esattamente come prima. Nota per il coordinatore: kamo-internal MarketDiscountsTab.tsx finestra di dialogo di modifica Gift-card invia attualeBalance oggi e che il campo sarà ora silenziosamente ignorato - una regolazione-equilibrio dedicato punto finale (mirroring /stock-levels/{uid}/adjust) dietro il proprio diritto è il corretto fix e ha bisogno di una decisione del prodotto, non una nuova unilaterale RoleRightType. Fisso anche nel passaggio mentre ri-deriving queste firme: creareShipment leggi l'ordineId dal posto sbagliato (il controller stava passando orgId posizione dove apparteneva l'ordine; l'interfaccia utente invia sempre ordineId nel POST corpo) - ora legge ordineId dal corpo, che è quello che ogni chiamante già manda. Questa è una soluzione funzionale, non una di sicurezza. Test: RetailServiceOrgScopingTest e... coprire una risorsa rappresentativa per modello di repository (colonna di org, via-parent join) con una lettura/aggiornamento/aggiornamento/dimostrazione che non riesce senza la correzione e una chiamata di stesso-org che ha successo, più il dono-card mass- regola di assegnazione. Mutation-checked: rifare le ricerche per trovareById fatto tutti i nove test "foreign org" falliscono rosso; restaurati prima di commit.