WikiNi

ToDoPublicationDeWikiNiVersion050

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes 38.107.191.106
Cette page liste toutes les étapes utiles pour la publication de la version 0.5.0 (non encore publiée).

Dernière ligne droite

Todo dernière ligne droite


Toute dernière minute


Après la publication




Hors 0.5 (une 0.6 va sortir quelques semaines après 0.5)
Les pages de documentation manquantes ne seront pas publiées, tant pis.




Contenu de la 0.5

Le contenu de la version 0.5 est maintenant figé. Toute nouvelle fonctionnalité est renvoyée à la version suivante. Le contenu est le suivant :












Problème de l'ActionEditActionsACLs?
Besoins premiers :
Cahier des charges proposé par CharlesNepote :
Mise en oeuvre proposée :
A l'installation du wiki :
Je ne suis pas pour :
-- CharlesNepote
Pour moi il n'est vraiment pas nécessaire de sortir une telle infrastructure parce que les risques sont faibles (un admin sait ce qu'il fait normalement) et par conséquent:
En outre je note que de tels mécanismes ne sont pas en place dans d'autres logiciels (je prends pour référence le cas de Linux où un sudoer pourrait supprimer le compte root ainsi que tous les sudoers y compris lui-même...).
Ironiquement je constate que la solution proposée consiste à intervenir sur le fichier de config pour ne pas intervenir sur la base. Personnellement je ne trouve pas ça véritablement mieux... (pour moi il est plus simple d'ouvrir PhpMyAdmin que de commencer à manipuler des fichiers par ftp...).
  1. Encore faut-il avoir accès à phpMyAdmin ! Dans de très nombreuses entreprises (et notamment la mienne), il y a une organisation ou la "prod" est séparée du développement. Les développeurs font ce qu'ils veulent sur les plateformes de "dev" et de "recette", mais ils n'ont pas accès à phpMyAdmin sur la plateforme de "prod". Toute modification des bases de prod est effectuée, soit par des applications référencées, soit par les admin dba -- avec, pour chaque demande, des délais en conséquence. (Beaucoup d'opérations sont ainsi interdites en prod : créations/suppressions de tables, etc.) En revanche, il est assez simple pour les développeurs de publier en prod un fichier modifié (en utilisant un outil de publication ad hoc basé sur SVN (je ne rentre pas dans les détails)). Bien sûr ce modèle ne concerne pas forcément les petites entreprises ou les hébergements mutualisés, mais il est extrêmement répandu dans les grandes entreprises. Si bien que dans ce cas, il est, de loin, beaucoup plus simple et sans délai, de modifier un fichier.
    • Je comprend tout à fait ton argument sur la séparation production/développement, qui est tout à fait logique et classique. Cependant il faut bien faire attention au problème auquel on s'adresse ici hein: c'est un cas où l'admin, qui est supposé responsable, fout la m***e soit par ignorance (mais alors pourquoi l'avoir mis comme admin s'il ne sait pas se servir de l'outil ?), soit par volonté pure de foutre tout par terre. Franchement, je ne vois pas pourquoi on devrait se soucier d'un problème pareil. WikiNi n'a absolument pas pour objectif d'être un outil à très haut niveau de sécurité où chaque opération doit être contrôlée et validée, bien au contraire d'ailleurs si on vise la simplification.
    • Par ailleurs, puisque j'ai actuellement l'occasion de découvrir comment fonctionne un logiciel de gestion (TinyERP?, même si ce n'est pas encore une référence) dans le cadre de mon stage, j'ai demandé ce qu'il en était au niveau de la gestion des admins. La réponse est simple: si un admin supprime tout les admins, tant pis, il faut passer par la db pour résoudre le problème. De toute façon ça ne devrait jamais arriver... -- DidierLoiseau
  2. Par ailleurs, beaucoup d'utilisateurs de WikiNi l'ont justement choisi parce qu'il présente une installation facile, sans avoir à utiliser phpMyAdmin. As-tu pensé que beaucoup d'entre eux n'ont peut-être jamais utilisé phpMyAdmin, dont l'utilisation n'est vraiment pas évidente pour un non informaticien -- sans compter le côté abscon de SQL. En revanche, ces utilisateurs ont forcément utilisé FTP et savent au minimum utiliser un éditeur de texte. Très franchement, WikiNi n'aurait été que pour moi, j'aurais sérieusement réfléchit à ta solution, mais l'intérêt de WikiNi est justement de s'adresser à des non spécialistes.
    • Je pense aussi que beaucoup des utilisateurs qui choisissent WikiNi pour sa simplicité n'ont même jamais fait de php et osent à peine toucher au fichier de configuration. Dès lors ce genre de protection ne s'adresse certainement pas à eux, à moins que ce soit proposé lors de l'installation mais alors il faut que cela ne complique pas celle-ci... -- DidierLoiseau
  3. Avis personnel : pour un pirate, il est plus facile d'attaquer une base qu'un fichier. -- CharlesNepote
    • Peut-être... Du moins si c'est le cas c'est dû au fait que la plupart des logiciels multi-utilisateurs font plus d'accès aux bases de données que aux fichiers, et que, de ce fait, les failles ont plus de chances de se retrouver dans l'accès aux base de données. De toute façon on doit nécessairement avoir une partie de la gestion des droits qui se fait via la BDD, pour des raisons de simplicité (on ne peut pas modifier le fichier de config juste pour ajouter un utilisateur dans un groupe...). Par conséquent si un pirate parvient à avoir un accès à un niveau élevé de la sécurité, qu'il vire tous les admins ne changera plus grand chose: il pourra déjà faire tout le mal qu'il veut par d'autres moyens. Par ailleurs il me semble que le risque de piratage n'est pas très élevé pour un wiki (parce que cela ne présente pas grand intérêt vu que les pages peuvent déjà être modifiées librement...). -- DidierLoiseau
Par ailleurs je n'aime pas trop cette solution parce qu'elle complique assez la gestion des droits alors qu'il n'y a pas de demande avérée pour un tel mécanisme. Le besoin traduit plus une crainte qu'un problème véritable... Je ressors ici mon bouquin d'XP pour l'occasion et celui-ci me dit «Pas d'investissements spéculatifs» ou encore «YAGNI», à savoir qu'il ne faut rien coder parce qu'on pense qu'on en aura besoin, mais uniquement se dont on a besoin (sinon on perd son temps au risque que cela cause en plus d'autres problèmes plus tard).
Pour poursuivre sur XP, et si on veut vraiment une solution qui satisfasse tout de même ces besoins, alors DTSTTCPW: interdisons à un utilisateur de se retirer lui-même du groupe admin. Même s'il retire tous les autres, il pourra encore les remettre dedans par la suite. De plus faisons du groupe admin un vrai groupe aux pleins pouvoirs, c'est à dire dont les membres satisfont n'importe quel test CheckACL.
-- DidierLoiseau

Franchement, je trouve qu'on pinaille un peu. D'après ce que je comprends, l'unique différence entre nos deux solutions est que dans ma proposition on ajoute un petit test à la con pour savoir si l'utilisateur n'est pas enregistré dans le fichier de config. S'il y a 3 lignes de codes qui diffèrent, c'est, je pense, le bout du monde. Si tu y es absolument opposé je me range à ton avis, je ferais les hack nécessaires pour mes déploiements... N'hésite pas à décrire ta solution complètement pour que tout le monde puisse bien comprendre. -- CharlesNepote

Pour détailler ma solution, c'est en fait assez simple, mais cela se base sur une vision omnipotente des admins:
L'implémentation
-- DidierLoiseau

Je propose :

1. Si installation

2. Si mise à jour de WikiNi 0.4

3. Si mise à jour de WikiNi 0.5


Discussions

Pour publier rapidement une version 0.5 propre, nous sommes remontés à la version du 2006-09-22 du trunck :
Nous y avons ajouté diverses fonctionnalités décrites plus haut.

Relayé pour la version 0.6 :


Lister quelque part toutes les possibilités rendues possibles par la création des acls sur les actions et les handler :

Pour archives à reclasser

Il y a 5 commentaires sur cette page. [Afficher commentaires/formulaire]
Éditer cette page :: 2007-12-29 05:40:11 :: Propriétaire : CharlesNepote :: Rétro-liens :: Cartographie :: Recherche :
XHTML 1.0 valide ? :: CSS valide ? :: -- Fonctionne avec WikiNi 0.5.0 (interwiki)