Reprise du message précédent :
switch 10G cuivre ou optique ?

J'ai la maison de câblée en cat6 (16 prises), donc je tente d'abord 1 liaison en cuivre pour tester. Puis SFP+ de toute façon, puisque dans la baie pour serveur et NAS, les DAC ça coute moins cher
 
Et vu que toutes les prises de la maison n'ont pas forcement besoin de 10G, j'ai pris ça (switch 24 ports 1G cuivre, 4 SFP+).

Pour ceux avec des laptop en TB : https://www.amazon.fr/SoNNeT-SOLO10 [...] merReviews

J'en prendrai peut être un si besoin ici

https://stackoverflow.com/questions [...] n-database ?
(mot clé : deferrable )

edit : après verif, il semble que sqlite n'ait pas de deferrable unique , désolé

pas de fallback en USB dommage

Ptite question dev.

Sur un projet perso (NodeJS, React, MySQL) j'ai besoin d'ajouter un système de droits. Un genre de matrice des droits.

En gros un utilisateur peut être admin d'un groupe, il ajoute des gens dans son groupe. Et moi, super admin, je donne accès à des features et s'il peut simplement lire le contenu ou bien le modifier. Par exemple une feature "SONG". Le groupe aurait donc la clé "SONG" et les utilisateurs du coup "READ_SONG", "WRITE_SONG" par exemple.

Je pensais avoir un tableau pour chaque utilisateur contenant les clés de ses accès, et un simple middleware (ExpressJS) qui check s'il peut accéder à la route. Donc sur chaque route j'ai juste à check si la clé attendu est bien contenu dans le rôle de l'utilisateur.

Vous avez une meilleure idée ? Pas de truc overkill, c'est pour un dev simple et rapide.

tu fout les autorisations dans un token JWT
le middleware vérifie  la présence et la signature du token sinon force une reconnexion
chaque endpoint ouvre le token et regarde les droits dont il a besoin sinon 403

tu pourrai faire la verif des droits dans un middleware, mais ça veut dire qu'il doit connaitre exactement quels droit vont à quelles routes, je préfère faire la verif des droit dans le endpoint concerné (genre /song ), car lui sait qui à le droit de faire quoi

J'ai déjà un token JWT qui est check à chaque routes. Donc le middleware est déjà en place. C'est comme ça que fonctionne ExpressJS.

Le truc c'était surtout de savoir si stocker un tableau de clé pour chaque utilisateur vous semble à chier ou pas.

Pourquoi ne pas donner les droits READ_SONG et WRITE_SONG directement au groupe ?
En gros t'as des droits (exemple : READ_SONG et WRITE_SONG) que tu peux filer à des users ou à des groupes.
Et à la connexion tu fais l'union des droits du users et des droits des groupes auxquels il appartient, ça te donne les droits complets du users.

Ouais c'est aussi l'info que j'ai trouvé

J'ai fait ça dans une transaction un peu dégueu, tant pis

 
Bah parce que un utilisateur dans le groupe peut ne pas avoir le droit de READ ou WRITE.
 
Mais en effet l'union est pas mal.
 
L'idée d'ajouter la feature directement au groupe, c'était plus pour le front, qu'ils sachent direct quelle groupe à accès à quoi etc. Et surtout aux admins pour savoir quelle groupe à accès à telle ou telle feature.

J'ai pris du 400 Mb, vous me faites peur maintenant  

L'union c'est de loin le + simple pour gérer des droits (en étant toujours en permissions qui ajoutent des droits).
La "feature" c'est des groupes de permissions en fait Ça peut vite ajouter de la complexité, notamment à l'affichage des droits d'un user.

Plus simple je sais pas. Car si les droits sont pour chaque utilisateurs, pour moi c'est plus simple, j'ai juste à check si l'utilisateur a le droit d'accès à cette route ou non.

Car un utilisateur peut être dans un groupe qui a READ_SONG, mais l'utilisateur PEUT être interdit à cette route. Donc le fait de check dans le groupe ET dans l'utilisateur sert pas à grand chose quand j'ai juste à regarder dans l'utilisateur. Je sais pas si je suis très clair.

Mais ma question de base c'était : stocker un tableau stringify en bdd mysql c'est pas déconnant pour ce cas donc.

Comment il peut être interdit ton user s'il a une permission READ_SONG ?
 
Pour le stockage, mets ça dans un champ JSON dans ton MySQL

 
Bah justement, le groupe à accès à la feature. Car ceux qui gèrent l'app (super admin) donne accès à certaines features à un groupe. Mais dans ce même groupe, des utilisateurs peuvent ne pas avoir le droit d'accès à cette même feature.

C'est une demande.  

Car en gros, ils veulent vendre certaines features à des responsable de "groupe". Mais ensuite, les admin de ce groupe peuvent décider qui à accès ou non à cette feature parmi les utilisateurs de ce groupe.

Faut formaliser un peu mieux comment marche ton truc alors, genre c'est une intersection de sets? Ou bien une soustraction? Ou bien tu as des droits positifs et des droits négatifs? Et il se passe quoi quand un user est membre de plusieurs groupes?

Pour résumer :

Le fait d'ajouter la clé de la feature dans la table des Groupe, c'est juste pour les "super admin", pour donner l'accès à cette feature à un groupe. En gros que l'admin d'un groupe puisse ajouter READ/WRITE aux utilisateurs.
Ensuite, un utilisateur ne peut pas être membre de plusieurs groupes.

Donc ma solution c'était que chaque utilisateur ait un tableau de clé, qui lui donne accès à telle ou telle route.
Et que les admin de l'app décide quel groupe à accès à cette feature.

Exemple : Les proprios de l'app vendent une feature "Gestion des images" à une guilde. Et donc les admin de la guilde décident ensuite qui peut voir ou upload des images parmi les membres.
Le fait d'ajouter la feature "IMAGE" dans la table de la guilde permet aux admin de l'app de savoir qui à accès à quoi (ce qu'ils ont vendu). Et ça permet ensuite aux admins de la guilde de pouvoir ajouter/supprimer les droits de cette feature à ses membres.

Ensuite, si un utilisateur va sur la route /images, je check s'il a la clé "READ_IMAGE" pour lui donner la ressource.

La guilde peut avoir accès à la feature "IMAGE" mais certains membres de cette guilde peuvent être interdit d'accéder à ca.

Je sais pas si c'est plus clair.

 
à mon sens tu te fais chier à mort, et ça va etre une usine à gaz à gérer.
 
je ferais ça avec 2 groupes : un groupe feature-admin qui décide qui a le droit d'assigner le groupe feature à un utilisateur, et un groupe "feature" : si tu en fais partie tu as accès à la feature, sinon pas. Du coup toute ta logique métier devient très simple.
Si je comprends bien tous les comptes n'auront pas accès à la feature, mais ça j'imagine que tu le gères via des feature flags et donc que tu as déja cette logique.
 
Du coup :  
- pour rajouter un user au groupe Images, ma guilde doit avoir la feature activée, et je dois etre dans le groupe image-admin
- en tant qu'admin de la guilde, je peux voir tous les membres de qui ont accès à la feature image, simplement en listant les membres du groupe image
 
je rate un requirement ?

Jubi a raison tu vas te faire chier avec une usine à gaz style Confluence/Gitlab la pour les droits et ça va être une galère sans nom
Essaye un modèle plus simple comme ça

Après y'a une gestion de READ et de WRITE aussi parmi les features. Je vois pas comment save ton système en BDD. Enfin comment ça peut être plus simple que mon système.

Avec mon système, quand tu veux accéder à une route, j'ai juste à check si "READ_FEATURE" est dans ton User.role, et ce truc, il est déjà en place en fait. (moi je file juste un coup de main sur ce projet, j'ai rien établi ou décidé à la base).

dans mon "système" la simple présence dans le groupe te dit si tu as la feature ou pas. De ce que j'ai compris de ton système, tu dois checker la présence dans le groupe, ET une règle qui peut etre spécifique à chaque utilisateur. Ton système est plus flexible, mais tu dois gérer bien plus de cas puisqu'on peut "override" au niveau de l'utilisateur ses droits précis. La gestion de ça devient plus merdique.
 
pour la BDD, je verrais un truc comme ça :  
- une table qui liste les features, par exemple qui contiendrait "image"
- une table de jointure features_users qui contient l'ID du groupe, l'ID de l'utilisateur, et le type de droit (read ou write, ou autre, tu dois pouvoir modéliser admin avec)
 
du coup si tu veux savoir quelles sont les features auxquel un user a droit, tu fais  

 
mais je présume d'après ton commentaire que tu veux utiliser un framework, auquel cas je sais pas ce que le framework prévoit pour la gestion de droit. Il n'en reste pas moins que je resterais avec des groupes simples. Si tu dois commencer à gérer des opérations ensemblistes sur tes droits, tu vas te faire chier très fort, parce que ta combinatoire de cas va exploser

Ok c'est plus clair, en effet c'est pas mal.

Non j'utilise pas de framework. NodeJS/ExpressJS pour le back, et React pour le front. Y'a pas 50 features mais seulement 5 ou 6 max.

Actuellement les routes avec ExpressJS sont de la forme :

Il y a un checkJWT pour recup le user qui fait l'appel et son user.role. La méthode suivante, checkRole, regarde s'il a le droit ou non d'accéder à cette route.

Ensuite pour update les droits, côté front y'a un tableau simple où tu coches (ou enlève) les accès pour chaque utilisateurs donc ça te génère un truc du style : ["READ_FEATURE1", "WRITE_FEATURE2"], et j'update le user avec ce tableau et terminé.

Sérieusement, tu viens demander des idées, des gens t’en donnent, et ensuite ils doivent les défendre pour que tu les considères sérieusement ?
 
Tu voulais juste des compliments?

Bah non, et je les remercies. La solution de Jubi est très bien et me convient.

Mais on me dit que ma solution est usine à gaz, alors que je trouve pas, donc j'explique juste ma vision de la solution et ce qu'il y a déjà de mis en place.

Et pour la 4ème fois, je rejoins un projet déjà en place ET je venais juste pour savoir si stocker des clés dans un tableau direct en bdd c'était ok ou pas pour ce genre de cas. Et sinon en quoi c'est de la merde.
C'est ça ma question de base, si tu le comprends tjs pas après l'avoir répété 4 fois je peux rien pour toi.  

C'est beaucoup plus clair.
 
Du coup je ferai ça (si tu veux de la 3ème forme normale ) :

 
Un groupe possède des users et des features.
Une feature possède des permissions.
Les users ont des permissions.
 
Du coup pour récupérer les permissions d'un user :

SELECT P.name
FROM permission P
JOIN user_permission UP ON UP.permission_id = P.id
JOIN user U ON U.id = UP.user_id
JOIN GROUP G ON G.id = U.group_id
JOIN groupe_feature GF ON GF.group_id = G.id AND GF.feature_id = P.feature_id
-- le critère GF.feature_id = P.feature_id te garantit que seules les permissions des features actives d'un groupe sont accessibles
-- (par exemple si à un moment tu vires une feature d'un groupe, tu peux te contenter de shooter la ligne dans group_feature)
WHERE U.id = %user_id%

 
Je distingue les features des permissions car ce n'est pas la même notion (même si elles sont liées).
 
Pour modéliser, j'ai utilisé https://dbdiagram.io/d avec ce code (si tu veux jouer avec) :

Le mec me fait même la requête. Même si y'a un ORM dans le projet je crois.

Merci beaucoup, plus "complexe" que ma solution mais plus pérenne et évolutive et surtout plus propre.

 
han le mec il normalise et tout    

On vous apprend pas ça chez Google ?

Dites, chez vous aussi, Microsoft installe ses merdes sans rien demander ?
 
Ces derniers temps, j'ai droit à Microsoft Photos (j'en veux pas, j'ai déjà Lightroom), et une merde appelée Photos Media Engine, et le pire étant la pub pour Office 365 (alors que j'ai Office Pro, thank you very much). Et à part le crapware Office, le reste on ne peut pas le désinstaller.  
 
Je vais encore devoir utiliser un script adhoc pour virer leurs merdes, je sens.

Chez Google, ils font du BigTable, c'est le contraire de normaliser.

On nous apprend à gérer le trade-off perf / resource de stockage / maintenabilité

Mais oui j'ai appris les formes normales de Codd, MERISE, etc... Mais j'ai aussi assez vite appris qu'en vrai les gens denormalisent au moins partiellement assez souvent

Je trouve aussi que Windows est redevenu super pushy pour te forcer à utiliser d'autres produits MS, le pire étant Edge et OneDrive :
- si tu cherches "chrome" dans Edge y'a une bannière spéciale qui te dit que Edge c'est mieux
- changer le browser par défaut montre une popup demandant si on veut vraiment ne plus utiliser Edge (popup qui n'apparaît pas sur les autres types MIME genre pdf)
- invariablement Edge va se remettre en navigateur par défaut en prétextant d'un problème avec Chrome pour supporter les fichiers .htm
- ne pas configurer OneDrive est une alerte de sécurité dans le centre de sécurité (sous prétexte qu'il faut des backups, alors même que Google Drive est installé). Voyant comment mon beau père flippe a chaque notification du genre, je ne demande combien de gens activent OneDrive de ce fait)
- à l'installation on peut créer un compte local non rattaché à Windows Live (ça permet notamment de choisir son username en ligne de commande, et évite le truc par défaut). Choisir cette option déclenche pas moins de 3 questions demandant si on est BIEN sûr, avec tous les UI tricks à la con genre mettre le bouton non en énorme et le "continuer avec ton approche kamikaze de merde" en police 8 en bas de l'écran

Je pense qu'on se ferait démanteler pour même pas 10% de ça

 
C'est d'ailleurs très casse-couilles, et plus ça va plus c'est difficile à chopper. Je sens arriver le jour où l'UI va bloquer cette possibilité...

buuurn !

Y’a aussi le fait que si tu veux initialiser une install Windows sans avoir à créer un compte, t’es maintenant obligé de déconnecter ton ordi d’Internet sinon il ne te propose même plus l’option...
 
Y’a longtemps que je serais full Linux si jamais je n’étais pas joueur...

 
 
Sans créer un compte Microsoft ? T’es pas obligé de déconnecté internet, mais l’option est un peu chiante à trouver.

la dernière fois je ne l'ai pas trouvé, obligé de couper le wifi

En parlant de comptes microsoft...
 
 
A la maison j'ai créé des comptes à tout le monde pour utiliser le contrôle parental pour l'ouverture des sessions Windows et la durée d'utilisation (le bureau est à l'étage, le grand a son PC dans sa chambre, bref...)
 
Bah ça suffit pas, bordel. 2 fois de suite (sur les 2 PCs sur lesquels il a un compte), il s'est levé la nuit, a changé la date et l'heure du bios et débranché le câble Ethernet pour pouvoir ouvrir des sessions en pleine nuit (genre à 3h du mat' avec tête à l'envers le lendemain, evidemment)
 
Du coup en attendant mieux, il y a maintenant un MdP sur les bios de tous les PCs, et par acquis de conscience il a l'obligation de descendre son PC dans notre chambre pendant la nuit.. Mais ça me gonfle d'avoir à en arriver là.. (et accessoirement, d'être dépendant de Microsoft pour ça, même si c'est quand même bien pratique d'avoir la possibilité de lui donner des droits à distance, et de contrôler à la louche qu'il fait pas tourner des jeux quand il dit qu'il bosse)
 
S'il y en a qui ont le même genre de problème, quelles solutions vous avez ? (et "jouer sur la confiance" n'est pas une réponse valable : on essaye régulièrement, mais il y a systématiquement des abus dès le jour 2)
 
 
Autre truc : on parlait de gestionnaires de MdP, récemment, et Dashlane était bien placé .. Version gratuite ou payante ?  

Bon en même temps, l’intérêt de Windows 10 réside aussi en partie dans l’utilisation d’un compte Microsoft. Je vois pas tellement de raison de s’en priver.