Permessi granulari basati su gruppi per utenti anonimi e registrati

Notizie ed Eventi Annunci
1

Nel nostro codice esiste storicamente un pseudogruppo confuso chiamato @everyone, che può essere utilizzato per:

  • Impostazioni del sito di tipo group_list
  • Permessi delle categorie
  • Gruppi di tag

In alcuni casi, le persone interpretano @everyone come “tutti gli utenti anonimi e tutti gli utenti registrati”, mentre altre lo intendono come solo “tutti gli utenti registrati”. La realtà, per le impostazioni del sito, è che nella maggior parte dei casi significa solo “tutti gli utenti registrati”.

A complicare ulteriormente le cose è il fatto che questo gruppo @everyone può essere utilizzato in impostazioni del sito dove non ha senso concedere l’accesso a “tutti gli utenti anonimi e registrati”, come ad esempio pm_tags_allowed_for_groups.

Questa situazione crea confusione anche dal punto di vista del feature flagging e dell’esperienza degli sviluppatori, poiché per alcune modifiche future o altre impostazioni potremmo voler abilitarle realmente per “tutti gli utenti anonimi e registrati”.

Soluzione

Stiamo introducendo due nuovi pseudogruppi automatici distinti:

  • anonymous_users (ID 4) - Rappresenta gli utenti anonimi che visitano il tuo sito senza un account
  • logged_in_users (ID 5) - Rappresenta tutti gli utenti registrati del tuo sito, con un effetto simile al gruppo automatico trust_level_0, ma più specifico

Questi gruppi sono già stati introdotti, ma avranno effetto solo quando la modifica futura granular_anonymous_and_logged_in_groups_permissions verrà abilitata sul tuo sito.

Quando la modifica futura sarà abilitata, qualsiasi impostazione con everyone come gruppo selezionato verrà automaticamente tradotta nell’ID logged_in_users, quindi nessun dato nella tabella delle impostazioni del sito verrà modificato al momento dell’attivazione della modifica futura. Quando la modifica futura diventerà permanente, eseguirò una migrazione dei dati per tutte le impostazioni dei gruppi per applicare questa modifica.

Inoltre, abbiamo segnato anonymous_users come disallowed_group per diverse impostazioni del sito dove non ha senso, ad esempio personal_message_enabled_groups.

image
image1217×205 51.6 KB

I conflitti con i nomi di gruppi esistenti vengono gestiti automaticamente, rinominando i gruppi esistenti e aggiornando le menzioni nei post.

E per i permessi di tag e categoria?

Questi permessi rimarranno invariati, poiché il loro concetto di “everyone” è diverso in alcuni aspetti e non si basa sul gruppo automatico sottostante.

8 Mi Piace
Db:seed_fu fails on 002_groups.rb during upgrade: Validation failed: Name has already been taken
3

Aspetta… cosa? :flushed_face: Significa che tutte le categorie che sono ora pubbliche (tutti) diventeranno chiuse e richiederanno l’accesso quando questa funzionalità verrà attivata?

4

No, perché:

Questo influisce solo sulle impostazioni del sito di tipo elenco gruppi che attualmente permettono di selezionare “tutti” come segue:

image
image909×273 54 KB

1 Mi Piace
5

Qualcuno può aiutarmi a capire come devo modificare i componenti del mio tema?

Ho provato a usare il componente copy-post come esempio, perché ricordo che utilizza anche un’impostazione di gruppo che concede l’accesso alla funzionalità. E che c’era un problema perché il gruppo fittizio “everyone” richiedeva un controllo separato, proprio come nel mio componente, poiché il confronto degli ID dei gruppi a cui l’utente appartiene non è sufficiente: quegli ID devono essere verificati separatamente. Per questo motivo mi aspettavo un recente cambiamento lì, perché, per quanto ne so, anche i nuovi gruppi sono gruppi fittizi e l’ID dovrebbe essere verificato separatamente. Mi sto perdendo qualcosa che spieghi perché ciò non sia necessario qui?

Il mio componente favorite filters ha due impostazioni di gruppo: una che permette ai gruppi di salvare i propri filtri e una che offre filtri standard.
Di default, solo i membri del gruppo trust_level_0 possono utilizzare filtri personalizzati, poiché solo gli utenti registrati possono avere dati memorizzati in un campo utente personalizzato. Quindi qui avrebbe senso se non permettessi anonymous_users come selezione. Come posso farlo in un componente del tema? Esiste già un esempio per questo?

L’impostazione predefinita per i filtri predefiniti è «everyone», perché trovo utile che anche gli utenti non registrati possano vedere e utilizzare i filtri predefiniti. Il problema è che everyone cambia in «logged_in_users» anche se l’ho selezionato specificamente. Devo creare una migrazione personalizzata per questo, in modo che gli amministratori che attualmente utilizzano everyone continuino ad avere filtri per gli utenti non registrati in futuro? Quando deve avvenire questa migrazione? O ogni amministratore deve modificarlo individualmente dopo che hai eseguito la migrazione?

Tutto ciò di cui mi sto preoccupando è davvero inutile? Se sono necessarie modifiche, meno di quattro settimane sembrano un lasso di tempo piuttosto breve, dato il numero di componenti mantenuti dalla comunità che potrebbero essere potenzialmente interessati.
Oltre a «copy-post», ho anche esaminato il componente unanswered filter, ma non ho trovato alcun cambiamento nemmeno lì. Sembra che stia trascurando qualcosa di importante. Dopo tutto, la modifica è stata abilitata di default da quasi una settimana. Per questo motivo ipotizzo che i componenti ufficiali sarebbero già stati aggiornati se fossero state necessarie modifiche.

1 Mi Piace
6

3 post sono stati uniti in un argomento esistente: Modernizzazione del tema Foundation

7

Guardando questi componenti, currentUser?.groups non è comunque affidabile, poiché include solo i gruppi visibili per l’utente, mentre i gruppi in cui si trova e che influenzano i permessi potrebbero non essere serializzati qui:

Nei core/plugins aggiriamo il problema facendo cose del genere nel serializzatore dell’utente corrente:

Ma ovviamente, questo non è disponibile per i componenti del tema e i relativi impostazioni.

Hmm, non sono sicuro, ci devo pensare. Se intendevi davvero everyone, allora dovrebbe essere cambiato sia in logged_in_users CHE in anonymous_users. Questo era il problema principale di everyone, come dichiarato nel post originale: alcuni pensavano significasse solo utenti loggati, altri intendevano loggati + anonimi, ed era molto dipendente dalla situazione.

Ho scelto l’interpretazione «solo utenti loggati» perché era più sicura dal punto di vista della sicurezza.

No, semplicemente non ho considerato i componenti del tema e le relative impostazioni e come sarebbero stati influenzati da questa modifica; mi ero concentrato principalmente sulle impostazioni del sito. Cose del genere saranno particolarmente difficili da individuare, dato che non utilizza nemmeno la costante AUTO_GROUPS:

image

Comunque, elaborerò alcune soluzioni a questi problemi e non sposterò questa modifica su Stable finché non avrò trovato una soluzione.

2 Mi Piace
9

Aggiornamento rapido: ho un’idea su come gestire la cosa e stiamo conducendo alcune discussioni interne al riguardo. Spero non richieda troppo tempo :crossed_fingers:

1 Mi Piace