Permessi granulari basati su gruppi per utenti anonimi e registrati

Notizie ed Eventi Annunci
44

No, non lo era, e lo abbiamo visto emergere più e più volte internamente ed esternamente, e in tutto il codice.

Non sono ancora arrivato alle categorie, qui non è cambiato nulla.

Le persone usavano in modo schiacciante TL0 per indicare “tutti gli utenti registrati” perché non avevamo un modo migliore di rappresentare questo. Il gruppo logged_in_users almeno è del tutto chiaro su cosa comporta, e non c’è assolutamente nulla che ti impedisca di continuare a usare TL0/TL1 ecc. L’unico gruppo che viene rimosso è everyone.

Sì, certo, sto facendo tutto questo solo per “il gusto di cambiare” :+1: Ti prego, considera per un momento le tue parole, non abbiamo l’abitudine di fare cose totalmente inutili senza motivo qui. Questo lavoro è in corso da mesi e non sta cambiando direzione.

3 Mi Piace
45

Ok, forse sto fraintendendo questa modifica?

Se la proposta è introdurre:

  • anon
  • logged in

come gruppi automatizzati

sembra tutto a posto e sono autoesplicativi.

(In realtà mi piace piuttosto! :+1:)

Se invece la proposta è in definitiva rimuovere:

  • everyone

questo non mi ha senso, poiché everyone fa parte di una serie di gruppi automatizzati che rappresentano soglie di accesso e che includono anche:

  • trust_level_0
  • trust_leve_1

ecc.

Tutti rappresentano soglie di accesso, incluso everyone.

Il gruppo everyone è aka “trust_level_none”

È un modo conciso per indicare l’accesso pubblico.

Apprezzo che non stiate proponendo di rimuoverlo per le autorizzazioni delle Categorie al momento (:+1:), ma personalmente vorrei vedere un impegno a mantenere questo gruppo automatizzato, perché per me almeno ha senso.

e poi perché non permetterne l’utilizzo altrove, proprio come fareste con qualsiasi gruppo automatizzato di livello di fiducia?

altrimenti, ovunque dobbiate esprimere che qualcosa ha “accesso pubblico”, dovrete aggiungere due gruppi, il che sembra una complessità inutile?

a che serve aggiungere logica per “mascherare” “everyone”?

forse un altro approccio alternativo è riconsiderare il nome “everyone” se esiste un nome migliore, ma mantenere il suo significato, la sua funzionalità e la sua disponibilità su tutta la piattaforma, e poi tutti (tosse) saranno contenti?

46

Credo che la distinzione qui riguardi il mantenere un modo comodo per selezionare “accesso pubblico” e il mantenere il gruppo everyone esistente. Concordo sul fatto che dover selezionare due gruppi ogni volta che si desidera l’accesso pubblico sia più macchinoso, e possiamo migliorare la situazione con l’interfaccia utente.

Ad esempio, potremmo aggiungere una scorciatoia “Pubblico” al selettore di gruppi che selezioni sia anonymous_users che logged_in_users con un’unica azione. Vedresti quindi entrambi i gruppi selezionati e potresti rimuoverne uno. Questo ti darebbe la comodità che stai descrivendo, mantenendo al contempo i permessi sottostanti espliciti. Offriremmo quella scorciatoia solo dove entrambi i gruppi sono consentiti.

Il problema con il mantenere il gruppo everyone esistente è che non ha sempre significato “accesso pubblico”. Per la visibilità delle categorie lo fa, ma per la maggior parte delle impostazioni basate sui gruppi del sito ha effettivamente significato “tutti gli utenti connessi”. Inoltre, ci sono temi e plugin che lo interpretano in modo diverso, come ha mostrato la discussione sopra.

Quindi non possiamo semplicemente mantenerlo e dire che include gli utenti anonimi ovunque, senza il rischio di concedere un accesso che prima non c’era. Mantenere il suo comportamento esistente preserverebbe l’incoerenza, e rinominarlo non risolverebbe il problema.

Un gruppo universale definito in modo coerente sarebbe possibile, ma richiederebbe comunque la migrazione e l’audit che stiamo facendo ora. Dovrebbe anche essere vietato ovunque l’accesso anonimo non sia supportato, altrimenti torneremmo alla situazione in cui “everyone” significa “solo utenti connessi” in quei luoghi. Ci sono un’infinità di impostazioni dove ho dovuto aggiungere anonymous_users come valore di disallowed_groups dove prima non c’era, e dove prima everyone era consentito. Ad esempio:

Preferirei fornire quella comodità nell’interfaccia utente, utilizzando i due gruppi espliciti sottostanti, in modo da avere coerenza ovunque per amministratori e sviluppatori.

2 Mi Piace