Bonjour
Après une recherche rapide sur le sujet, je suis tombé sur un message de l’ancien forum Scenari (Anciens forums SCENARI :: Voir le sujet - Utilisation du protocole SFTP pour la publication ?).
Je me demandais si un tel développement c’est fait entre temps, si quelqu’un en a eu écho ?
De même, en essayant de comprendre le fonctionnement de GenDeploy FTP, je ne trouve pas de documentation 
Tout ce que je vois dans l’item GenDeploy c’est la collecte des informations (adresse serveur, login, mdp…) mais comment sont traités ces données derrières ?
Merci pour vos infos
Cordialement,
Christophe Scherrer
Bonjour,
Je plussoie, l’usage de SFTP serait vraiment utile, je ne peux pas
utiliser FTP pour déployer à l’UTC typiquement.
Et en effet, la question du stockage des infos est également une
question pertinente, je pense que c’est en local dans le client lourd,
sans chiffrement ?
À suivre,
Stéphane.
Je précise :
On commence à avoir des usages variés à l’UTC (Picasoft, Api…) et dans
ces contextes on ne publie pas vers un ScDepot (et il n’y a pas de
serveur FTP, mais bien un serveur SSH).
Aujourd’hui il faut donc faire un push à la main avec Filezilla ou
rsync. Ce n’est pas « bloquant », mais dès que j’insère de nouveaux
utilisateurs c’est tout de même très limitant, soit ils doivent de
demander de MAJ, soit je leur apprends à le faire, soit il font des
erreurs… J’ai également écrit des scripts pour automatiser un peu,
mais ça reste bancal (et finalement pas super pratique).
Voilà pour la qualification du besoin.
Je ne sais pas si c’est le genre de fonction qui pourrait être déléguée
à un dev communautaire ?
A+
Steph.
1 « J'aime »
On s’est replongé dans ce code (qui date d’une quinzaine d’année 
), il y a quelques semaines (pour l’ihm web en 5.0)… Ce vieu code est en effet problématique : c’est un simple push ftp sans sécurité, ce qui n’est clairement aujourd’hui plus acceptable.
On a rapidement regardé, on pourrait à priori le recoder pour n’autoriser que du SFTP, au prix d’un alourdissement de l’application SCchain-desktop (de quelques Mo supplémentaires).
Concernant le stockage des données, c’est actuellement en local dans SCchain-desktop, sur serveur dans SCchain-server et pas chiffré. Je pense donc qu’on va virer la persistance du mot de passe en 5.0, même si ca risque de faire grincer des dents chez les utilisateurs… Les considérations de sécurité ont évolué depuis 15 ans!
J’avoue que nous hésitons aussi avec l’option de totalement supprimer ce déploiement FTP, jamais utilisé dans nos contextes pro.
Mais si la communauté nous remonte que cette fonction de déploiement FTP est utilisée, ca nous motivera pour la remettre à niveau…
Très difficilement non, c’est intégré à notre architecture interne.
Par contre développer des « petits serveurs » compatibles avec le protocole CID (en PHP, etc) pouvant aisément s’intégrer dans plateformes d’hébergement externes (ou des extension/plugins de CMS), pour permettre la diffusion de contenus Scenari via ce protocole CID me semblerait une très bonne idée ! Thibaut avait codé une 1ère version PHP de démo très simple à une époque…
On pourrait coacher les personnes que ça intéresserait.
1 « J'aime »
- Sur la persistance du mot de passe, laissons le choix en précisant où et comment c’est stocké (je pense que Filezilla ne fait pas mieux)
- Regardez la solution paire de clés SSH (pour le coup c’est la bonne solution avec Filezilla) ; ça permettrait et de rester conforme aux standard de sécu et de permettre à ceux qui ont de bonnes pratiques de ne pas être embêtés (et donc de sous-évaluer Scenari de ce point de vue)
- Concernant la suppression de la fonction :
- débat légitime, donc appel à la communauté : vous utilisez, vous n’utilisez pas ?
- j’utilise encore la fonction genDeploy sur mon serveur OVH qui a un serveur FTP
- J’ai exposé mon usage, il est important de mon côté, je ne pense pas que le déploiement sur du Depot soit systématisable (ou alors il faut parler de ça). Si on élargit les usages avec un éditeur Web qui permettra d’impliquer plus de personnes dans la chaîne, la question de la fonction de publication va se poser de façon plus fréquente.
Encore un point pour rebondir sur ma question de dev « communautaire », ne peut-on envisager un module « externe » pour cette fonction ?
En web (SC 5.0), ce sera plus facile en injectant un bouton de diffusion spécifique simplement codé en JS, mais cela restera peu performant : téléchargement du résultat de la génération sur le poste client puis envoi vers la cible. Via CID, on passe directement de serveur à serveur.
Bonjour,
Dans nos contextes, il est parfois difficile de réclamer du FTP au lieu du SFTP… on continue à me laisser un accès FTP pour faire du genDeploy, mais on me fait de plus en plus comprendre (à juste titre), qu’il faudrait passer a minima à du SFTP !
Y a t’il quelque part des specs pour développer des « petits serveurs » compatibles CID ? Cela pourrait aisément entrer dans des projets d’élèves si un cahier des charges pouvait être clairement défini avec ce type de specs.
Bonjour
Je vois que mon message a suscité pas mal de réaction, merci à tous.
Comme Fabien, je suis preneur d’infos autour du serveur CID qui pourrait être une bonne solution dans mon contexte. (Documentations, exemple de Thibaut cité par Sylvain…)
Au plaisir de vous lire 
Christophe
Bonjour à tous,
Désolé d’avoir mis un peu de temps à répondre ! Comme promis par Sylvain, voilà quelques infos sur CID :
-
Qu’est ce que c’est ?
On a conçu CID (pour Content Interactive Delivery) comme une couche d’abstraction aux différents protocoles de communication permettant l’échange de contenus ou de métadonnées entre serveurs. L’enjeu est de permettre à la fois un déploiement automatisé des contenus (c’est à dire, en renseignant le moins d’information technique possible) et une médiation par un usager (je suis auteur et l’ihm du serveur distant me propose de renseigner des métadonnées ou un chemin de déploiement avant de déposer le contenu). -
Mais techniquement, qu’est ce qu’on fait ?
On va distinguer deux serveurs, celui qui envoie le contenu (serveur source, par exemple chez nous chain) et celui qui reçoit le contenu (serveur cible, par exemple chez nous depot).
Le serveur cible doit proposer un manifeste XML accessible derrière une simple requête HTTP(S?) non authentifiée. Ce manifeste décrit des processus (de déploiement de contenu… sélection, etc.) et la couche technique sur laquelle ces processus reposent (REST, Service unique HTTP, on pourrait imaginer d’autres protocoles techniques ici).
Le serveur source peut alors récupérer ce manifeste et automatiser ce qui devient automatisable (choix du type de requête HTTP, de la façon de passer les métadonnées, etc.) laissant à l’usager le soin de renseigner ce qui est plus fonctionnel que technique.
La particularité de CID est de prévoir à la fois un mode de d’interaction technique de serveur à serveur et un mode d’interaction fonctionnelle laissant le soin au serveur source d’afficher une ihm web produite par le serveur cible ce qui permet à l’usager d’interragir avant ou après déploiement avec le serveur cible. -
Pour aller plus loin
On a publié un petit site sur le sujet il y a quelques temps : Accueil [Content Interactive Delivery]
Avec un doc de prise en main : Homepage [Discover CID] et un doc de spec Homepage [Specification: CID protocol]
Le doc de prise en main fait des liens vers les sources des implémentations (simplistes !!) de demo en PHP. Ça fait quelques années que ces docs (ou les exemples PHP) n’ont pas évolué. Je prendrai le temps dans les prochaines semaines de vérifier tout ça et de remettre à jour ce qui le mérite.
En attendant, n’hésitez pas à poser des questions, j’y répondrai avec plaisir.
Le principal problème est que l’implémentation actuelle est ni SFTP, ni FTPS, mais seulement FTP !
Idéalement il faudrait que nous implémentions les 2, mais pour FTP(S), les principes de sécurité voudraient que nous alertions l’utilisateur en cas de communication en clair avec du simple FTP, ce qui complique un peu plus le problème. Le passage à SFTP serait probablement plus simple que d’implémenter le couple FTP / FTPS.
Pour CID, tout son intérêt réside dans la possibilité de spécifier un processus complexe d’interactions impliquant les 3 acteurs « utilisateur - client - serveur ». Les protocoles que tu cite ne traitent que le cas trivial à 2 acteurs « client - serveur ».
News sur ce sujet : un gen deploy « SFTP » a été intégré dans SCENARI5 (en plus du FTP)
Yaaaawp !
Merci.
Merci pour cette bonne nouvelle Antoine 
Hâte de voir les mises à jour !
Pour être complet :
Limite de l’implémentation SC5.0 : l’authentification par SFTP par paire de clef SSH n’a pas été intégrée pour le moment. Seule l’authentification par mot de passe est implémentée.
Explication : tous les développements actuels nous obligent à une double compatibilité XUL (client lourd actuel) et WEB (apporté par SCENARI5). Il nous a semblé disproportionné à ce stade d’avancement de SCENARI5.0 de passer du temps sur ce sujet pour le rendre fonctionnel dans l’environnement XUL, amené à disparaître à moyen terme.
On pourra donc faire un autre pas sur ce thème dans SCENARI 5.1 ou 5.2, lorsque l’environnement XUL n’existera plus (ou avant si il y a une grosse pression sur le sujet )