Dans beaucoup de cas, il s'agit simplement d'un cahier ou classeur contenant un résumé de la journée, signé par le responsable. En réfléchissant un peu, j'ai rapidement fait l'analogie avec les blogs. En Suisse, les signatures numériques (GPG par exemple) sont reconnues comme étant valide (au moins autant qu'une signature manuscrite).
Je me suis donc mis en tête de trouver un logiciel de blog qui me permettrait de faire tout ça :
- Signature GPG des billets
- Authentification LDAP
- Gestion des droits simples (apprenti écriture, formateur signature uniquement, personnes authentifiées lecture uniquement)
- Multi-utilisateurs (plusieurs apprentis et/ou formateurs)
- Fichiers textes (pour le stockage des billets)
- Langage creole
Je me suis donc fait un cahier des charges du blog de mes rêves (en fait j'ai failli partir dans le développement d'un petit truc à la rache (ISO 1664), mais j'ai réfléchi).
Ensuite je me suis dis qu'il y aurait peut-être d'autres personnes intéressées par ce projet. Il est même possible que ce blog existe quelque part (mais bien caché). Il se peut même que d'autres personnes aient des idées intéressantes à ajouter au cahier des charges. Et pire encore, il y a peut-être des gens intéressés à participer au développement de ce blog.
Il s'agit donc d'une sorte de "Request For Comments" avant que je me lance dans le création de ce blog.
PS: Bien entendu ce blog est (sera) en licence GPL.
# Dokuwiki en fait une partie (mais pas tout)
Posté par AP . Évalué à 2.
- l'authentification LDAP
- la gestion des droits (potentiellement dérivés de groupes d'utilisateurs de l'annuaire)
- les utilisateurs multiples
- le stockage sous forme de fichiers texte plutôt que sous formes d'entrées dans une base de données
En revanche...
- Son langage n'est pas le creole même s'il s'en rapproche
- Il ne dispose pas nativement de fonctionnalités de signature des pages et aucun plugin allant dans ce sens ne semble pour l'instant disponible... encore que le développement de plugins pour dokuwiki ne semble pas trop compliqué... Peut être est-ce à creuser.
[^] # Re: Dokuwiki en fait une partie (mais pas tout)
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Mais toute la partie "wiki" pose problème. C'est des fonctionnalités à, presque, supprimer (ou du moins désactiver). Donc niveau charge de travail je sais pas si c'est le mieux. Surtout pour amputer pleins de fonctions à un excellent outil.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Dokuwiki en fait une partie (mais pas tout)
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
# La RACHE
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
[^] # Re: La RACHE
Posté par Anthony F. . Évalué à 4.
# AGPL
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Sous GPL seule, rien n'empêcherait quelqu'un de le modifier lourdement, sans publier ses modification, et de l'utiliser pour héberger des gens sans respecter leur liberté.
Avec AGPL, il devrait publier ses modifications à ses utilisateurs.
[^] # Re: AGPL
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Django
Posté par monde_de_merde . Évalué à 1.
Gère directement où via des plugins quasiment tout ça.
L'exception étant la signature par GPG des billets mais à l'aide de la boîte à outils de python il doit être possible de bidouiller trés rapidement et de manière assez solide.
Une gestion des droits fine permettrait de mettre en place les limitations que tu souhaites (y compris l'impossibilité de la dé-signature et de la modification).
Le stockage dans une base de données se fait de manière très simple, et je crois qu'il existe un pluggin pour utiliser des fichiers textes (au pire une base SQLite qui est standalone elle et ne nécessite rien en sus de python pour être exploitable).
Je pourrais continuer comme ça mais là n'est pas le sujet, en bref :
C'est comme ça que je ferai.
Coté désavantage :
Le fait que tu cherches quelque chose de standalone est un soucis mais les package python (les eggs) gèrent relativement bien les dépendances, et dans le cas présent tu pourrais assez facilement te limiter à Django, si tu acceptes de recoder 2 ou 3 trucs. Et sinon juste l'installation de 2 pluggins pour Creole et LDAP.
[^] # Re: Django
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Ce projet serait prévu pour des apprentis, formés avec PHP, et des entreprises qui tournent, pour la majorité, avec Windows Server.
Au cours professionnel, l'installation d'un serveur Web Apache/PHP/MySQL est fait sur Windows (si, si, c'est terrible mais c'est comme ça (Linux entre dans les cours, mais c'est pas encore ça)).
Donc utiliser du python c'est prendre un chemin qui assure que le projet sera utilisé que par moi, ce que je ne souhaite pas (sinon je serais parti à La RACHE (c'est bon comme ça l'orthographe ?)).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Django
Posté par lolop (site web personnel) . Évalué à 2.
L'admin sys du parc a juste à installer un VirtualBox (ou du même genre).
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Et les blogs existants ?
Posté par Moogle . Évalué à 2.
[^] # Re: Et les blogs existants ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et les blogs existants ?
Posté par Uriel Hossman . Évalué à 1.
- c'est le seul moteur de blog qui m'est venu à l'esprit en lisant ce journal
- je ne l'ai pas testé donc je ne sais pas ce qu'il vaut
- il est open source et respecte les standards
- je l'ai trouvé là bas sur opensourcecms.com ( http://php.opensourcecms.com/scripts/show.php?catid=2&ca(...) ).
J'espère que ça vous aidera dans votre recherche :)
# Extension Firefox
Posté par Aurélien Bompard (site web personnel) . Évalué à 2.
Ensuite, je serais d'avis d'ajouter les fonctionnalités manquantes à un moteur de blog genre dotclear ou wordpress, comme l'indique le commentateur précédent.
[^] # Re: Extension Firefox
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Pour Wordpress et Dotclear, il semble que ce soit base de données uniquement, de plus il me semble qu'il faut changer tout le rendu pour qu'on puisse utiliser du creole comme langage.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Pourquoi faire simple…
Posté par nicoastro . Évalué à 4.
Bon c’est clair que ça en jette moins.
[^] # Re: Pourquoi faire simple…
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
L'apprenti signe son message, ce qui empêche le responsable de le modifier, et le responsable signe le message signé.
Ça pourrait fonctionner, même plutôt bien, mais je trouve ça moins intuitif qu'un blog, par contre niveau travail à faire : rien, tout est déjà en place (serveur mail, gnupg, un mailman (ou similaire)).
Mais je vais quand même rester sur l'idée du blog, je crois qu'il faut un truc intuitif.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pourquoi faire simple…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Pourquoi faire simple…
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Ensuite le rendu c'est pas top. Soit les mails en HTML (que je m'efforce de proscrire parce que je suis un vieux con) pour avoir les liens hypertextes (pratique dans un journal de travail) ou soit en texte avec des liens[1]
Donc c'est pas le plus intuitif qui soit à mon sens. Finalement si on a plusieurs apprentis, ça va faire quand même un peu charlot d'avoir X fois 3 mails contenant le même contenu (et en plus en terme d'économie de place c'est pas le plus optimale).
[1] hypertextes
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# «Blocage de la suppression d'une signature»
Posté par StreakyCobra . Évalué à 2.
La pérennité des données va dépendre du bon vouloir de la personne ayant la main sur le blog, ou sur ton support WORM (si tu comptes utiliser cela). Dans ce dernier cas on peut toujours imaginer que quelqu'un détruise le support de donnée. Pour être sur qu'une signature ne puisse être effacée, je te conseille d'utiliser une des caractéristiques des signatures numériques (Signature_numerique). Elles sont irrévocables, ce qui signifie que d'une fois une signature établie, la personne qui l'a mise ne pourra nier l'avoir fait. Les parties en présences (Apprenti, Formateur) devraient donc signer numériquement les deux le billet, et d'une fois que cela est fait, récupérer chacun de leur côté le fichier doublement signé. Ainsi il n'y a pas de main-mise sur les données de la part d'une ou l'autre de parties. De plus la signature attestera si le texte qui a été signé est bien le texte contenu dans le fichier et rendra donc caduque toute modification apportée après la signature.
J'opterai aussi pour un fichier XML contenant deux parties, une première contenant l'article et une autre contenant les signatures. Rien ne t'empêche après d'utiliser du créole dans la partie «article/» pour la mise en forme.
exemple:
«billet»«article»{Texte de l'article}«/article»
«signatures»
«signature»{Signature de l'apprenti de la partie contenu dans «article/»}«/signature»
«signature»{Signature du formateur de la partie contenu dans «article/»}«/signature»
«/signatures»
«/billet»
Ainsi ton fichier XML, d'une fois récupéré, atteste que l'apprenti et le formateur ont les deux signés le billet. Et si un jour vérification doit être fait de l'intégrité des signatures, la clef publique de chacune de parties permettras de vérifier si l'article qu'ils ont signés et bien celui contenu dans la balise «article/». Si tel est le cas il NE pourront NIER avoir signé ce billet, aussi bien le formateur que l'apprenti. Quand à la récupération automatique des fichiers j'opterai pour un flux RSS à la manière des podcasts, pour permettre à chacun une relève automatique des fichiers (d'une fois signés bien sûr).
Pour le reste des fonctionnalités, cela s'apparente plus à du web pur et dur et j'imagine bien qu'il ne devrait pas trop y avoir de problèmes.
En espérant que ça aille pu t'être d'une quelconque utilité :)
Fabien
PS: Désolé pour le XML pas tant «conforme», mais je n'arrivais pas à mettre les bonnes balises.
[^] # Re: «Blocage de la suppression d'une signature»
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
L'apprenti aura accès aux serveurs (il apprend le métier et l'administration des serveurs de la boîte en fait partie), donc ouvrir un fichier texte sur vi, taper "dd:wq" et la signature n'est plus là. Le formateur aussi peut le faire. En cas de litige, le formateur/apprenti peut supprimer quelque signature et dire "voilà personne n'a contrôler mon travail, ...".
Donc éviter que la signature soient supprimée, la méthode c'est la réplication. Il y aura sur les bandes de backup le fichier signé, si l'apprenti ne fait plus confiance à son responsable (en cas de litige), il peut copier les fichiers sur un CD-Rom, sur son serveur d'hébergement gratuit, sur son gmail, sur son disque dur USB. Le formateur aussi.
Nier la signature on ne peut pas le faire (à moins de prouver que l'apprenti a eu accès à la clé privée et au mot de passe du formateur), mais c'est protéger la suppression de la signature elle-même qui est important. Dans ton exemple de fichier "2dd:wq" et il n'y plus de signatures.
En fait ce qui est important :
- Que l'apprenti fasse son journal de travail (obligation légale)
- Que le formateur lise le journal de travail et le signe (obligation légale)
Donc la signature de l'apprenti n'est pas importante (possible, mais pas nécessaire). À aucun moment l'apprenti va dire "je n'ai pas fait mon journal de travail" c'est lui qui est pénalisé.
Par contre il devra contrôler que le formateur ne supprime pas des journaux (pour dire "il n'a pas fait son travail"), là la signature n'aide en rien. Par contre on peut imaginer qu'à chaque exportation des données le système appose une signature lui appartenant pour prouver que les données viennent bien de lui (je vais ajouter ça (en fait juste une liste de somme de contrôle de chaque fichier, cette liste étant signée par la clé du système)).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: «Blocage de la suppression d'une signature»
Posté par StreakyCobra . Évalué à 1.
On peut imager ça tel un contrat réalisé sur papier: il est fait à double exemplaire, et chaque personne garde une copie du contrat munie des deux signatures. Dans votre cas, chaque personne signe le billet, et ensuite récupère une copie du billet doublement signé.
Si quelqu'un modifie le billet original sur le serveur pour supprimer les signatures, l'autre personne à une copie du fichier sauvegardé chez lui, et peut prouver que l'autre personne l'avait effectivement signé, ceci dans un sens comme dans l'autre.
L'idée de la signature de l'apprenti, c'est plus dans l'idée ou le projet serait sous une licence libre, et qu'il risque d'être réutilisé dans d'autres sociétés avec des formateurs peu scrupuleux. Les apprentis doivent aussi avoir le droit de se défendre en cas de malveillances du formateur.
[^] # Re: «Blocage de la suppression d'une signature»
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
b88d14ee22bdd7d7ad5978cd91805ac540ff63d6606c4700464e4eb3c32924d3 fichier1.txt
135a0df2fa26c6be9de03462f45539d2b5bce286f34bebbe1b112cde14a97afc fichier2.txt
a4f086b848a1883bd7933e3f04e50a8bf4a538fc90b6cc6cea175ae0b33d824a fichier3.txt
3b662c91914cedfd75e25dcc8a1621fc6dc64a29307d984dbd6fe49977cf6935 fichier4.txt
98a3bfde6619b2aa6df15cd532c64f1949b3c045feb62f47616e198cb364c640 fichier5.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Fausse signature
iQIcBAEBCAAGBQJK8aIHAAoJEMFfL/bTFBa4kUgQAIaeNtpeu+B1hb/djbjt1tKk
B3upiJP4pFQVnt9SMCu9Rp4FPLxAsuchRN80uJB4QlFzJuGmLi4HvHKBf23M1PHm
6z8QH+UFYlMo2DPkRw+480KmJp9PpdxTvoYXwI02NLGuJrolZ9+IfqQLRvpcv/OH
j4r9UkZzHq/cEzBo5tK0QSOBupBY8p5xkaGQ8LwvUd9ZwvE0rpC3Rz9pT40kGpn8
K3mHLB+Ui0xZt8Oa3TdM506t9qyuWNooGaU91LEGGdJ0SeIGKzRolQYiMxQwmMHa
WYUKhGd+X1pmifTpvTXZEtsBmX/DjSzswV4ihjUdUMaGpTPAgAavbgA4/YcVEhVR
URAKEYjHQtaTvhPgCdcjzDDzaZ0uIeKuR8zjbwieCNDgY1GQpbCxlfrZzSHUdYX6
5U1m/Bb0u42OYJZXE+sz8pwbF92KxkWSqC/e6+K4OOrknvUI27cU8kcEhGcsLgOf
gI+f4Vt30pi6fEFAEMy39I3LKDePC45UK2EFxrYVVHhZZN+q1hPIY2dIQG57ci4l
u/d9lnzI24f6tB5edIt3AnuJoWsXnEdp1zCYvrkYZ3JAYHdsautEugn5F5d23Z35
Y0IBhVdvSsiTPbxHjoOlL4r1UxOTYn8m46kdkr0cY+/3O4Sh5BFUIkTeHkrGu+W5
QXO4VhcEYEKcIi7Rj6c4
=RRLN
-----END PGP SIGNATURE-----
Permet d'obtenir le résultat souhaité (preuve que l'apprenti fait son travail et que son travail n'a pas été modifié) et reste plus simple à gérer.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: «Blocage de la suppression d'une signature»
Posté par StreakyCobra . Évalué à 1.
[^] # Re: «Blocage de la suppression d'une signature»
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Donc on ajoute les signatures des deux (et en du coups d'autant de personnes qu'on veut). Comme les fichiers _doivent_ être au format wiki creole (pas de xml), on peut utiliser les balises <<>>.
Genre :
<<>>
Aujourd'hui blablabla ...
<<>>
<<<signature:etienne@example.com: [signature] >>>
<<<signature:paul@example.com: [signature] >>>
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: «Blocage de la suppression d'une signature»
Posté par StreakyCobra . Évalué à 1.
Je me mets à la place des développeurs qui n'aimeraient sûrement pas devoir réaliser un parser pour analyser ton fichier, mais utiliser simplement les outils XML existants pour séparer les signatures de l'article
Enfin je dis ça dans un souci de perfectionnisme. C'est clair que ça complexifiera un peu la tâche pour afficher les articles dans le blog. Mais je me dis que tant qu'a faire les choses, autant les faire bien non ;-) ?
[^] # Re: «Blocage de la suppression d'une signature»
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
- C'est une syntaxe wiki (13 wikis la supportent, d'autres sont en cours), donc syntaxe simple à apprendre et utiliser
- C'est pas ISO ou W3 ou ... mais c'est une collaboration entre plusieurs projets de moteur wiki
- C'est lisible facilement par l'être humain
- Ça contient tous ce qui est nécessaire
- Il existe des parsers pour Java, Perl, Python, Javascript et PHP.
- Écrire journal de travail en XML c'est pas ce qu'il y a de plus pratique.
- Mélanger _deux_ syntaxes (XML comme enveloppe du document wiki creole) alors qu'une seule contient tous les éléments, ce n'est pas la meilleure solution
- Si on sépare en deux documents, RDF en Notation 3 aurait ma préférence
Faire du XML n'implique pas "faire les choses bien".
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: «Blocage de la suppression d'une signature»
Posté par totof2000 . Évalué à 3.
En fait la personne à qui tu réponds ne fait que me conforter dans mon idée : les devs utilisent de puls en plus XML par confort, au détriment des utilisateurs
Je cite :
Je me mets à la place des développeurs qui n'aimeraient sûrement pas devoir réaliser un parser pour analyser ton fichier, mais utiliser simplement les outils XML existants pour séparer les signatures de l'article
Jen e veux pas relancer le débat que l'on a eu par ailleurs, mais cette phrase est symptomatique. Attention, je ne dénigre pas l'usage de XML, je trouve ça très bien pour des documents tels openoffice, SVG, etc .... qui sont des documents qui normalement n'ont pas à être manipulés par des humains. Par contre, lorsqu'il doit y avoir manipulation humaine (fichier de conf, wiki), je trouve que XML n'est pas approprié.
[^] # Re: «Blocage de la suppression d'une signature»
Posté par StreakyCobra . Évalué à 1.
Mais dans ce cas je pensais effectivement à une enveloppe XML contenant ton article au format creole. Ça c'est une question de goût et si tu penses que les balises creole conviennent parfaitement pour l'usage dont tu as besoin et bien ... départ :-) !
# Les grandes lignes sont tracées
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Les grandes lignes sont tracées
Posté par téthis . Évalué à 2.
Un identifiant d'une forme plus simple ne ferait-il pas l'affaire ?
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Les grandes lignes sont tracées
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Sinon un hash aurait été possible, mais réellement ça change rien, je veux dire que le nom de fichier ait la forme "aaaa" ou "a-a-a-a", c'est du pareil au même.
Finalement en utilisant des uuid comme prévu par la RFC 4122, ça donne une garantie de pouvoir importer les données sur un autre blog sans risquer de collisions.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Les grandes lignes sont tracées
Posté par téthis . Évalué à 2.
Je ne conteste pas l'utilisation d'UUID, ça me donne seulement l'impression d'utiliser quelque chose de surdimensionné pour identifier les billets d'un blog.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Les grandes lignes sont tracées
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Sinon je crois pas que c'est surdimensionné. J'ai besoin d'un identifiant unique, c'est un identifiant unique qui fait 36 caractères de longueurs et c'est utilisé comme nom de fichier. Un nom de fichier de 36 caractères c'est raisonnable.
Le vrai problème, pour moi, c'est que ce n'est pas très "humain". Trouver un billet par son fichier est compliqué (il faut automatiquement un logiciel pour le faire), mais avec un script "sh" on arrive à le faire, donc c'est encore assez raisonnable.
Finalement je me laisse la possibilité de prévoir un répertoire "by-name/" qui contiendrait des liens symboliques ayant comme nom le titre du billet, la date, l'auteur, ... ou toutes les possibilités en même temps. Mais dans un premier temps, je penses que c'est déjà bien suffisant (parce que le "user-friendly" n'est pas prioritaire).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.