rss sur https...

[ionl]

Bonjour \o
Que dois je faire pour que Leed accepte mon flux rss en https ?
est-ce géré ? (je pense que oui mais comment Leed accepte le certificat ?)
mince ya le certificat et derrière j'ai un .htaccess ^^
A++

[cobalt74]

normalement ça marche déjà avec les flux https. Lors de la récupération du flux, on ne regarde pas le certificat.

déjà vu sur https://github.com/ldleman/Leed/issues/41

[ionl]

Re,

A feed could not be found at https://xxxxxxxxx/feed/. A feed with an invalid mime type may fall victim to this error, or SimplePie was unable to auto-discover it.. Use force_feed() if you are certain this URL is a real feed.

Pourtant mon flux marche bien dans le navigateur. A savoir que le site est protégé par un .htaccess. Donc Firefox : 1/ d'authoriser le certificat et d'ajouter l'exception 2/ login / pwd du htaccess.

Donc la forcement Leed doit bloquer sur le 2/ mais je ne vois pas comment contourner le souci.

[cobalt74]

ah bah moi non plus désolé !

[Sbgodin]

@Yionel si j'ai bien compris, le problème n'est pas HTTPS mais de pouvoir utiliser l'authentification HTTP dans pour un flux ?

Il n'existe pas une telle fonctionnalité, mais, par hasard, essaye un truc comme ceci :

https://login:pass@xxxxxxxxx/feed

[ionl]

ah yes bien joué ! ça marche. Par contre ça m'oblige à mettre mon mot de passe en clair que pourront voir les invités :)

Donc ça serait pas mal que Leed cache les données "login:pass@" dans : http(s)://login:pass@xxxxxxxxx/feed

Ces données sont présentes dans la gestion des flux mais aussi dans le title du href sur l'encadré en page d'accueil "Options des flux" (elles sont peut-être présentes ailleurs)

Merci

[Sbgodin]

Pas idiot, comme remarque. Je met cette notice en tant que suggestion pour un développement ultérieur. L'idée est donc de ne pas envoyer au client (le navigateur que tu utilises) de login/pass.

Cependant, le login/pass doit rester en clair du côté du serveur. Et un accès à la page de gestion doit/continuera à donner l'accès à la chaîne complète, login/pass compris.

Ça te va ?

[ionl]

Attention la page de gestion tout le monde y a accès donc non login mot de passe nulle part pour l'affichage. Le seul moment ou il est utile c'est quand le moteur va synchroniser les flux (la encore dans le rapport ne pas faire afficher les identifiants) Et les identifiants devraient être chiffrés en BDD

[cobalt74]

j'ai changé le label en suggestion et @Sbgodin à l'air bien partie pour le faire en v2

[ionl]

Cool merci à vous

[marienfressinaud]

Attention : il n'est pas possible de chiffrer réellement les identifiants en BDD : pour l'authentification il faut se connecter en login@password. Si le password est chiffré, on ne peut plus s'authentifier. Il faut peut-être avertir l'utilisateur de ce "soucis"

[Sbgodin]

@Yionel le login/pass ne sera jamais affiché nul part, donc. Ni pour l'utilisateur invité, ni pour l'administrateur. Il reste à trouver une solution élégante pour :

• Dire qu'un login/pass existe mais n'est pas visible.
• Changer le login/pass seulement si explicitement demandé.
• Conserver (même si pas réentré) le login/pass si le domaine du site n'est pas changé. Le seul truc qui me dérange encore est l'impossibilité de connaître le login/pass depuis l'interface web. La seule option restant alors d'aller lire la base de données qui contient toute la chaîne de connexion en clair.

[ionl]

@marienfressinaud > Le chiffrement c'est juste pour le stockage on déchiffre derrière. Un md5 suffira. Quand le script de synch s’exécute il déchiffre

@Sbgodin > une PCRE pour matcher tout cela et l'enlever à la volée.

[marienfressinaud]

@Yionel > le principe du chiffrement c'est de ne pas pouvoir être déchiffré justement. En principe tu ne peux pas déchiffrer une chaîne md5 (même si md5 a déjà été cassé). Alors oui pour "saler" le mot de passe afin de le cacher plus ou moins, mais à partir du moment où tu peux le déchiffrer, n'importe qui peut le faire aussi en principe : ce n'est plus vraiment du chiffrement.

[Sbgodin]

Je confirme que le MD5, comme tout condensat, ne répond pas au problème. Si on considère que le mot de passe est une donnée sensible, elle ne devrait pas être stockée dans la liste des flux. Mais ça oblige à d'autres développements non prévus, et peut-être un peu overkill par rapport aux besoins.

Je vois bien une bonne PCRE. C'est la partie facile. En interne, rien ne change ni le stockage des liens ni la synchronisation. C'est juste à l'affichage et à la modification du lien que ça se corse. En particulier, pour ne pas désorienter l'utilisateur.

Par exemple, si on ne peut jamais voir le mot de passe. Comment faire pour vérifier que c'est le bon ?

[ionl]

@marienfressinaud non. Le principe est de ne pas l'avoir en clair c'est tout. Rien n'est incassable ah mois d'utiliser des clés énormes avec des passphrases énormes (et encore) etc. La politique de pidgin par exemple est de tout mettre en clair car ils se basent sur le principe que le mec qui veut déchiffrer y arrivera. (je les comprends mais je n'y adhère pas, je préfère avoir une barrière qui filtre même si elle n'est pas parfaite)

@Sbgodin on ne vérifie rien du tout c'est le script de synchro qui s'en charge. Le flux est chargé c'est le bon mot de passe, sinon la synchr indique un problème comme actuellement.

Le mot de passe n'est pas sensible matériellement parlant. C'est juste un accès http(s) sur le serveur. Je ne vois pas ce qu'on peut faire avec. Il peut être sensible pour ne pas faire afficher les données aux autres

A++

[marienfressinaud]

Ne suffit-il pas de créer deux champs : un pour le login, l'autre pour le mot de passe (input de type password pour le dissimuler). Si jamais le mot de passe n'est pas bon de toutes façons l'utilisateur s'en rendra compte rapidement. Sinon une possibilité est de tester la connexion au moment de sauvegarder les identifiants (une requête HTTP qui renvoie un code d'erreur 401 signifie que l'authentification s'est mal passée)

Edit @Yionel > nous sommes d'accord qu'il ne faut pas stocker le mot de passe en clair, mais ça ne sert à rien d'enregistrer en md5 le mot de passe sachant qu'il faut le décrypter derrière. Ça risque de bouffer des ressources pour rien, surtout que md5 n'est pas fait pour être décrypté.

[ionl]

Oui oui je suis d'accord en plus j'ai indiqué le md5 mais c'est une fonction de hashage et non de chiffrement. Son seul avantage est justement de savoir rapidement si un mot de passe match quand on fourni... le mot de passe ^^

Après je ne m'y connais pas assez pour trouver un truc léger / rapide / fiable etc. :)

[Sbgodin]

@Yionel Dans le cas où la synchronisation révèle un soucis. Comment vérifier, uniquement via l'interface web et donc sans voir le mot de passe, qu'il est bien celui qu'on pense avoir entré ? Logiquement, il suffirait de l'entrer à nouveau pour vérifier. Mais l'utilisateur n'aurait plus le moyen de le vérifier pour de vrai, par exemple en copiant/collant l'url pour voir que « ça marche ». Ça stresse l'utilisateur. Sans compter s'il y a un bug d'encodage, etc. avec un mot de passe complexe.

[ionl]

@Sbgodin quand on lance une synchro manuelle l'interface indique les erreurs ou pas. Je pense que l'existant est suffisant.

0.322s | A la une - Google Actualités 0.355s | Actualités 0.779s | Actualités linux 0.630s | Alertes Qualitaÿ sur HFR 0.650s | Alsacreations.com - Actualités 0.673s | Android-France 1.057s | Articles 0.309s | XXXXX A feed could not be found at https://toto:toto@xxxxxx/feed/. A feed with an invalid mime type may fall victim to this error, or SimplePie was unable to auto-discover it.. Use force_feed() if you are certain this URL is a real feed.

[Sbgodin]

Il est justement question de ne plus du tout afficher les mots de passe, selon la demande initiale. Ni dans les logs, ni ailleurs. Comme tu l'as dit, tes utilisateurs pourraient le voir.

[ionl]

@Sbgodin Je réponds juste à ta question "Comment vérifier, uniquement via l'interface web et donc sans voir le mot de passe, qu'il est bien celui qu'on pense avoir entré " Si message erreur problème sinon identifiants ok

Après je vous laisse décider de comment rentrer ces identifiants :)

[Sbgodin]

L'interface de la synchro dit juste que le compte et le mot de passe ne sont pas acceptés par le serveur en face. Il ne dit rien quand à l'adéquation entre ce que je pense avoir entré et ce qui a effectivement été stocké par Leed. Et bien évidemment, comme tu le demandes, le mot de passe ne devrait pas être affiché.

[ionl]

euh ? si la requête envoyée avec le login et mot de passe est bonne, le script de synchro fait son job et ya pas de message d'erreur. Je ne comprends pas ce que tu veux dire.

Moi comme je l'entends pour le moment. Un endroit pour gérer ses identifiants par flux et c'est tout.

Si la synchro se passe bien c'est que ce que mes identifiants sont bons et donc sont adéquats (comme Sheila qui adéquat ^^)

[Sbgodin]

Je ne regarde pas le cas où la connexion se passe bien. À la rigueur, l'utilisateur s'en fout tant qu'il récupère les flux. Mais quand ça se passe mal, l'utilisateur (et moi le premier) veut résoudre le problème. Il peut retenter de rentrer le mot de passe, mais si ça ne marche pas ? Comment l'utilisateur pourra prendre connaissance du mot de passe existant (il n'a accès qu'au web) et savoir où il a commis une erreur - verrou majuscule, mauvaise recopie, erreur dans Leed.

D'ailleurs, même quand ça va bien. Il peut vouloir connaître le mot de passe entré, parce que c'est le même pour un autre flux par exemple.

J'ajoute enfin que cette contrainte de ne pas voir le mot de passe en admin brise une des vérifications de l'import/export OPML : s'assurer qu'un export des flux (format OPML), importé dans Leed puis exporté à nouveau ressorte identique. Or, l'export OPML sort les flux tels quels et fonctionnels. Donc les mots de passe sont présents dans le premier export et doivent être présents dans le deuxième. Si on retire les mots de passe de l'export OPML, alors l'utilisateur n'aura plus de sauvegarde complète de sa liste de flux. En cas de récupération sur catastrophe, de déplacement de l'hébergement ou simplement d'une mise à jour sauvage de Leed, ça va gueuler dans les chaumières.

[ionl]

Et ce que j'ai dit sur la gestion des identifiants par flux ? Leed n'a pas des logs pour tracer les erreurs de connexion ?

[Sbgodin]

S'il y a des identifiants par flux, si je comprends bien, ils seraient stockés à part. L'export OPML ne pourra les contenir, puisqu'il est accessible via l'interface. Cet export ne pourra pas servir de sauvegarde, il faudra en plus pouvoir récupérer ces mots de passe. Mais il ne faudra pas pouvoir les récupérer via l'interface... Ce serait un gros changement dans la philosophie de Leed.

Leed a des logs, bien sûr. On les voit soit via la synchro manuelle, soit via la synchro cron wget, soit via la synchro cron shell. Chacun d'eux contient l'url complète, mot de passe y compris.

En cas de mot de passe incorrect, la seule réponse apportée par le log sera de type Erreur 403. Le login/pass n'est pas accepté. Ça ne permet pas de copier/coller tout ça dans un lien pour tester, ni de dupliquer un lien pour accéder au même site, etc. Comment s'assurer que le mot de passe stocké (et compris par Leed) est bien celui que j'ai entré via l'interface ? Et comment assurer une sauvegarde correcte de Leed 1/ via le serveur 2/ via l'interface ?

[ionl]

1/ c'est quoi cette notion d'export ? 2/ pourquoi vouloir tester à tout prix l'url complete avec les mots de passe. On a une url on a les mot de passe que l'on peut changer et voir par l'interface. Je ne comprends pas ce qu'il faut de plus. On voit une erreur 403 parfait, ça suffit.

"Et comment assurer une sauvegarde correcte de Leed 1/ via le serveur 2/ via l'interface ?" pas compris

[Sbgodin]

@Yionel Leed peut exporter la liste des flux au format OPML. C'est accessible depuis le menu Gestion/Export. Le principe est de pouvoir exporter les flux dans ce format pour les importer où on veut. Typiquement, je veille à ce que l'export de l'import d'un OPML soit identique à l'OPML de départ. Cela me permet de savoir si tout s'est bien passé.

Leed ne gère pas du tout les login/pass. Il ne fait que passer tout le lien à une bibliothèque qui fait ça très bien. C'est pour ça qu'en l'état, le login, le pass et l'url sont intimement liés.

Tu as émis l'hypothèse qu'à partir de l'interface, on ne voit jamais les login/pass. Y compris quand on est en admin. Comment refaire une installation propre de Leed ailleurs rapidement ? Normalement, on fait une installation ailleurs et on importe le fichier OPML récemment exporté. S'il ne contient pas les mots de passe, il faudra des étapes en plus.

[ionl]

Ahhhhh je comprends mieux la problématique. Je ne connaissais pas OPML et la gestion des flux fait par Leed et ça change la donne. Hummm je pense qu'il faut y réfléchir à tête reposée.

Juste comme ça (avec fatigue et bière dans le museau) je pense qu'il faut garder l'export et la gestion actuel. L'export reste sans mot de passe quoiqu'il arrive (avec option d'exporter ou non ceux qui sont avec mot de passe), je crois qu'en plus on a pas trop le choix. Ensuite une petite popup pour chaque flux permettant de stocker les 2 identifiants lié à 1 flux. Dans le script de synchro, 1 requête au départ pour select l'ensemble des identifiants qui sont rajoutés lors de la requête.

Concernant l'export des mots de passe, la ca peut se faire par un dump de la table ou ils sont stockés et reliés avec une fk au flux. Après on peut réfléchir à un truc plus ergonomique style phpmyadmin qui a plein d'options d'export :-)

Car si je devais faire une réinstalle propre de leed ailleurs, j'utiliserai un dump complet sql.

De toute façon ce n'est pas du tout prioritaire comme bug, vous pouvez le tagguer en priorité basse (on peut le faire sous github comme sur redmine ?). Quels sont les stats d'utilisation d'un flux rss avec htaccess ? entre 0 et 5% ?

[Sbgodin]

S'il faut stocker les mots de passe en dehors du lien, il faudra profondément modifier la logique de la synchro. Actuellement, la synchro ne s'occupe pas de l'url. Elle ne fait que la transmettre à un composant extérieur. C'est donc une simple boucle sur les flux existants : si on gère les login/pass ailleurs, ça va compliquer la procédure. Quand j'ai remanié cette partie-là, @ldleman a dû passer un peu de temps à contrôler avant de fusionner. Je crois qu'il a hâte de recommencer.

Le soucis est qu'une clé étrangère (si j'ai bien compris) serait spécifique à une instance particulière de la base. On pourrait toujours l'exporter avec le lien complet (sans login/pass) en guise de clé étrangère. Mais cela rompt la simplicité de Leed dont la seule donnée importante à cette heure est le contenu du fichier OPML. Par exemple, il y a peu une personne avait un soucis avec son Leed. Un flux ne passait pas. Il m'a suffit d'avoir son OPML pour commencer le travail.

Il n'y a pas que les login/pass à protéger. PcInpact permet l'accès aux articles complets pour ses abonnés. L'accès est protégé par une clé unique pour chaque utilisateur. Comme pour le login/pass, c'est le genre de donnée à ne pas divulguer. Mais là, Leed ne disposerait d'aucun moyen standard de savoir ce qui est confidentiel de ce qu'il ne l'est pas !

En fait, j'imaginerai plutôt un statut public/privé par défaut, comme c'est le cas aujourd'hui avec des exceptions possibles par catégorie et par flux. Mais ce n'est pas pour tout de suite.

Ce ticket est taggé pour la v2.0. On a donc le temps d'y réfléchir.

[ionl]

"Actuellement, la synchro ne s'occupe pas de l'url" : ok je comprends la réflexion à avoir ^^

[ldleman]

Yop !!

Je n'ai lu qu'en diagonale (parce qu'il faut reconnaître qu'on pourrait écrire un bouquin rien qu'avec ce topic ^^) donc je vais peut être parler à coté de la plaque mais voila mon avis :

Un flux RSS est fait pour être lu et diffusé au maximum, placer un flux RSS en https je peux encore le concevoir, le placer en https PLUS authentification je trouve que c'est carrément de l'hérésie et que ça vas contre le principe de la diffusion.

Bref dans ce cas précis je pense que ce n'est pas à leed de faire un effort mais bel et bien aux Feeds qui se sont blindés de telles façon, sinon c'est la porte ouverte aux modifications de leed pour qu'il puisse aussi lire un flux RSS encrypté via VPN sécurisé à travers 12 firewall (ce n'est qu'un exemple, mais vous voyez ou je veux en venir).

Bref en faire éventuellement un plugin si c'est techniquement possible pourquoi pas (mais je ne m'en chargerais pas perso ^^) en revanche dans le natif on ne peux pas se le permettre désolé :)

[marienfressinaud]

J'ai un peu décroché du reste de la discussion mais :

Un flux RSS est fait pour être lu et diffusé au maximum, placer un flux RSS en https je peux encore le concevoir, le placer en https PLUS authentification je trouve que c'est carrément de l'hérésie et que ça vas contre le principe de la diffusion.

Je suis plus ou moins d'accord. Oui, en principe, sur un site, un blog ou que sais-je, un flux RSS est fait pour être diffusé au maximum. Ceci dit on peut très bien imaginer un flux RSS contenant des infos "sensibles". Typiquement, j'imagine très bien des logs d'une application dans un flux RSS. Seulement je n'ai pas envie que ça soit accessible à tout le monde et je le bloque derrière une authentification. Autre exemple : personnellement pour mon agrégateur je propose l'export des catégories, des flux, des favoris ou du stream principal par flux RSS. Seulement mon agrégateur est bloqué derrière une authentification HTTP : si je veux "exporter" le flux d'une de mes catégories dans Thunderbird par exemple il faut que je puisse m'authentifier en HTTP. Certes ce sont des exemples "non standards", mais il ne faut pas oublier que des fois les utilisateurs sont très imaginatifs ^^

[cobalt74]

Allé, je me lance.

@marienfressinaud je suis d'accord. Mais du coup, votre Leed n'est pas disponible en lecture à d'autres. Le problème serait donc réglé. non ? Pas besoin de cacher quelque chose de non visible.

[ldleman]

Ceci dit on peut très bien imaginer un flux RSS contenant des infos "sensibles"

Justement pour moi le flux RSS n'est pas conçu pour ça, dans le cas de logs ou d'infos sensibles à passer, il me parait plus logique de créer un webService spécialisé la dedans avec une authentification plus poussée.

Alors effectivement sur ce point ce n'est que mon avis, en revanche je peux tourner la choses autrement :

Si le RSS peux être fait pour ça (et ce n'est pas mon opnition j'insiste :p), Leed lui, n'est pas fait pour ça.

Surveiller des logs d'applications sensibles n'a jamais été son but, le but est de pouvoir regrouper,trier et gérer des actualités au format RSS :)

Si Leed s'embarque dans des utilisations non standard de RSS pour atteindre des objectifs en totale inadéquation avec son but originel on risque vite de finir en usine à gaz fourre tout et non fonctionnelle.

C'est une bonne chose d'avoir des utilisateurs imaginatifs, mais je n'en détruirait pas l'intégrité de Leed pour autant :)

[marienfressinaud]

@cobalt74 > je n'utilise pas Leed mais le principe est le même. Je veux cacher mes flux à part quelques-uns, pour cela je peux vouloir utiliser une instance "publique" qui a accès à l'instance derrière l'authentification HTTP. D'où l'intérêt de pouvoir gérer l'authentification HTTP

@ldleman > C'est ton choix et ton logiciel et je comprends tes arguments, tu fais comme tu veux :)

[cobalt74]

@marienfressinaud est ce que finalement, on est pas sur une fonctionnalité flux public / privé à définir sur chaque flux. Du coup bcp plus simple a mettre en place sans faire de grosses modifications ! L'objectif de Leed, c'est de rester simple et efficace. Les trucs exotiques c'est 1% de la population visée.

[Sbgodin]

@ldleman @cobalt74 C'est bien plus que un petit pourcent. Je reprend l'exemple de PcInpact. Les abonnés ont la possibilité d'avoir un flux RSS contenant tout l'article. Pas d'authentification HTTP, mais une clé à passer en paramètre. Si la presse en ligne fait du payant, ce type d'accès sera plus fréquent.

Concrètement, l'abonné récupère dans son espace le lien à copier/coller dans son flux RSS. C'est tout. Leed, ou tout autre lecteur RSS, n'a pas besoin de s'en occuper. Mon avis personnel, qui rejoint partiellement celui de @ldleman est qu'il faut éviter de toucher au lien d'un flux. Avec ou sans login/pass ou clé.

Ensuite, reste le problème de l'accès public. Les invités peuvent voir quelle est l'url derrière les flux. C'est conforme à l'esprit de Leed, mais pas compatible avec le caractère secret de certains liens. Or, Leed ne sait pas détecter une clé dans un lien. Ou alors, il faudrait spécifier quels sont les liens publics ou privés. Ou alors, plus encore et au-delà, transformer Leed en mandataire (proxy) RSS : il réémet les flux, les gens s'abonnant sur un lien pointant sur le Leed lui-même plutôt que la source d'origine. :no_good:

[ionl]

Pour le post de @ldleman (https://github.com/ldleman/Leed/issues/141#issuecomment-16644112) j'adhère (comme la colle Sader ^^) Pour le reste j'ai lu en diagonal aussi :p

[cobalt74]

@Sbgodin finalement ce qu'on est en train de dire c'est une option qui existe déjà. non ?

Autoriser la lecture anonyme Oui Non Nb: si vous choisissez cette option, les utilisateurs non authentifiés pourront consulter vos flux (sans pouvoir les marquer comme lu/non lu).

C'est peut être moi, mais je ne vois pas l'intérêt de partager ma bibliothèque de site que je consulte avec les gens (c'est carrément privé). Si je veux partager un sujet, j'utilise le plugin social (PUB ^^) pour initier les discutions sur les réseaux sociaux !

@Yionel tu as un vrai besoin de visualisation par des invités ? ou c'est juste pour faire la promo de Leed ? :)

[ionl]

@cobalt74 : non je n'ai pas de besoin de visualisation pour les invités :-)

[Sbgodin]

@tous, le problème des mots de passe étant indécidable puisqu'il peut se nicher dans l'authentification HTTP mais aussi en tant que clé de session, je propose de classer sans suite cette fonctionnalité. D'autant que, pour le moment, Leed est mono-utilisateur et l'interface d'admin ne devrait pas être accessible à d'autres.

[ldleman]

Oaip