Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #22757 > unrolled thread

Gestire chi "amministri" una tabella come nei gruppi di Whatsapp

Back to article view | Back to it.comp.www.php

Contents

  Gestire chi "amministri" una tabella come nei gruppi di Whatsapp ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-01 15:06 +0100
    Re: Gestire chi "amministri" una tabella come nei gruppi di Whatsapp Alessandro Pellizzari <shuriken@amiran.it> - 2019-11-01 15:21 +0000
      Re: Gestire chi "amministri" una tabella come nei gruppi di Whatsapp ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-01 17:18 +0100
      Re: Gestire chi "amministri" una tabella come nei gruppi di Whatsapp ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-02 19:23 +0100
        Re: Gestire chi "amministri" una tabella come nei gruppi di Whatsapp bramante <bramante@yopmail.com> - 2019-11-03 10:14 +0100
          Re: Gestire chi "amministri" una tabella come nei gruppi di Whatsapp ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-03 12:11 +0100

#22757 — Gestire chi "amministri" una tabella come nei gruppi di Whatsapp

Salve,

ipotizziamo di avere una tabella users, una tabella crews ed una 
companies; una company potrebbe avere più amministratori (users) e nella 
tabella crews inserirei le FK di users e di companies:

users
---------------
id_user	   name
1  	   John
2     	   Peter
3     	   Sam

companies
--------------
id_company name
1      	   Car rental USA
2    	   Restaurant Mr. X
3    	   Hotel Last way

crews
------------------------------------
id_crew FK_id_company FK_id_user
1    	1             1
2    	1             2
3       1             3
4       2             2
5    	2             3

Il mio dubbio ora è come aggiungere i diritti nella tabella crews ovvero 
come accade in Whatsapp quando si crea un gruppo decidere un 
amministratore e l'eventuale estensione dei poteri.

Forse dovrei aggiungere in companies un campo tipo administrator...

Saluti.
^Bart

[toc] | [next] | [standalone]

#22758

On 01/11/2019 14:06, ^Bart wrote:

> Il mio dubbio ora è come aggiungere i diritti nella tabella crews ovvero 
> come accade in Whatsapp quando si crea un gruppo decidere un 
> amministratore e l'eventuale estensione dei poteri.

Tieni sempre separate le ACL dagli utenti.

Questo ti permette di cambiare strategia di autenticazione e di 
assegnazione dei "poteri" semplicemente creando tabelle nuove e 
cancellando quelle vecchie, senza trovarti colonne inutilizzate.

Ma soprattutto ti permette di essere più flessibile nella gestione dei 
permessi.

Quindi non aggiungere niente a quello che hai, ma crea nuove tabelle, 
tipo amministratori(id_gruppo, id_admin), e/o permessi(id 
auto_increment, permesso varchar) + permessi_utenti(id_utente, id_permesso)

Bye.

[toc] | [prev] | [next] | [standalone]

#22760

> Tieni sempre separate le ACL dagli utenti.

Ottimo consiglio! :)

> Questo ti permette di cambiare strategia di autenticazione e di 
> assegnazione dei "poteri" semplicemente creando tabelle nuove e 
> cancellando quelle vecchie, senza trovarti colonne inutilizzate.
> 
> Ma soprattutto ti permette di essere più flessibile nella gestione dei 
> permessi.
> 
> Quindi non aggiungere niente a quello che hai, ma crea nuove tabelle, 
> tipo amministratori(id_gruppo, id_admin), e/o permessi(id 
> auto_increment, permesso varchar) + permessi_utenti(id_utente, id_permesso)

Bene, mi frullava in testa che la mia idea fosse "sbagliata" o 
quantomeno non la migliore per una eventuale scalabilità futura e tu in 
maniera chiara e precisa mi hai dato delle belle "dritte"! :)

Grazie!

> Bye.

Saluti!
^Bart

[toc] | [prev] | [next] | [standalone]

#22762

> Quindi non aggiungere niente a quello che hai, ma crea nuove tabelle, 
> tipo amministratori(id_gruppo, id_admin), e/o permessi(id 
> auto_increment, permesso varchar) + permessi_utenti(id_utente, id_permesso)

Morale della favola ho creato alla fine quattro tabelle:

users
-----------------------
id_user		name
1		Peter
2		John
3		Sam

userpermits
------------------------
id_userpermit	name
1		Administrator
2		MediumUser
3		NormalUser

restaurants
-----------------------------
id_restaurant	name
1		Mr. Pizza
2		Mc Nick
3		GoodLunch

restaurantcrews
---------------------------------
id_restaurant FK_id_restaurant FK_id_user FK_id_userpermit
1	      1		       1          1
2	      1                2          1
3             1                3          2

In questo modo solo chi è Administrator potrà ad esempio cambiare il 
nome del ristorante, gli altri prevedo possano cambiare ad esempio solo 
la tabella con l'orario di apertura!

In teoria potrei non mettere l'id_restaurant primary key ma lasciare che 
siano primary key tutte e tre le FK!

> Bye.

Saluti!
^Bart

[toc] | [prev] | [next] | [standalone]

#22763

Il 02/11/19 19:23, ^Bart ha scritto:
>> Quindi non aggiungere niente a quello che hai, ma crea nuove tabelle, 
>> tipo amministratori(id_gruppo, id_admin), e/o permessi(id 
>> auto_increment, permesso varchar) + permessi_utenti(id_utente, 
>> id_permesso)
> 
> Morale della favola ho creato alla fine quattro tabelle:
> 
> users
> -----------------------
> id_user        name
> 1        Peter
> 2        John
> 3        Sam
> 
> userpermits
> ------------------------
> id_userpermit    name
> 1        Administrator
> 2        MediumUser
> 3        NormalUser
> 
> restaurants
> -----------------------------
> id_restaurant    name
> 1        Mr. Pizza
> 2        Mc Nick
> 3        GoodLunch
> 
> restaurantcrews
> ---------------------------------
> id_restaurant FK_id_restaurant FK_id_user FK_id_userpermit
> 1          1               1          1
> 2          1                2          1
> 3             1                3          2
> 
> In questo modo solo chi è Administrator potrà ad esempio cambiare il 
> nome del ristorante, gli altri prevedo possano cambiare ad esempio solo 
> la tabella con l'orario di apertura!
> 
> In teoria potrei non mettere l'id_restaurant primary key ma lasciare che 
> siano primary key tutte e tre le FK!

giusto, togli id_restaurant e metti come primary key la combinazione dei 
3 campi.

valuta se nella tua applicazione sia meglio avere come gestione dei 
permessi Rbac o ACL, a seconda se il livello di accesso viene dato ad 
personam sulla risorsa o sul gruppo e i suoi ruoli.

dall'esempio che hai fatto la tua è una gestione dei permessi che meglio 
si adatta a Rbac.

Saluti


> 
>> Bye.
> 
> Saluti!
> ^Bart
> 

[toc] | [prev] | [next] | [standalone]

#22764

> giusto, togli id_restaurant e metti come primary key la combinazione dei 
> 3 campi.

Perfetto!

> valuta se nella tua applicazione sia meglio avere come gestione dei 
> permessi Rbac o ACL, a seconda se il livello di accesso viene dato ad 
> personam sulla risorsa o sul gruppo e i suoi ruoli.
> 
> dall'esempio che hai fatto la tua è una gestione dei permessi che meglio 
> si adatta a Rbac.

Si, credo che la logica sia nettamente più vicina al concetto di Rbac.

> Saluti

Saluti!
^Bart

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web