Attention à odoo: regardez le coût de maintenance et de mise à jour avant de faire votre choix (quelques recherches à ce sujet sur votre moteur de recherche préféré devrait vous donner des éléments d'information).
Nombre d'utilisateurs de odoo restent "coincés" sur des anciennes versions à cause des coûts de mise à jour / upgrade.
Posté par rycks .
En réponse au lien RIP HTTP.
Évalué à 5.
Dernière modification le 05 mai 2023 à 10:12.
Merci pour l'argument qui conforte encore plus ma position sur le sujet.
Et qui me conforte à penser que vous avez une vue très étroite du monde, la France n'est pas le centre du monde.
Le http/https imposé à l'ensemble des humains est un problème bien plus vaste.
Que chez toi dans ta France il te soit "interdit" d'utiliser une vieille r5 sur les routes officielles (mais que techniquement tu peux encore faire tourner pour peu d'avoir du carburant compatible) pourquoi pas … mais tu ne veux quand même pas rendre impossible son usage à un Malgache ? une Cambodgienne, un Thaï, une Mexicaine, un Péruvien ?
De même que monter à 3/4/5 sur une moto sans casque pour aller travailler sur le chantier.
Donc oui mon exemple de la voiture est tout a fait correct pour illustrer le problème.
C'est ça la réalité, rendre inaccessible un matériel informatique qui ne propose qu'un accès https (donc non pérenne) c'est empêcher son utilisation pour des raisons que je trouve absurdes.
Vraiment ouvrez les yeux et changez de nombril :-)
Posté par rycks .
En réponse au lien RIP HTTP.
Évalué à 10.
Dernière modification le 04 mai 2023 à 22:42.
Rappelons que ce qui est déprécié et viré actuellement est TLS 1.0 et 1.1 (et les SSL), pas HTTP qui marche toujours, donc on ne parle pas du tout des gens qui son sur un réseau sûr au bout du monde, ils peuvent toujours utiliser HTTP même avec le dernier Firefox, le site en lien est pour le fun pour le futur très lointain, sans gêner tes exemples.
Mais relis moi … je demande à ce que http perdure, je ne demande pas à ce que tls1.0 soit accepté en 2050. Non je demande à ce qu'en 2050 je puisse encore me connecter à l'interface d'admin du photocopieur, du point d'accès wifi, de la console de gestion d'un serveur etc.
Je prends l'exemple de l'abandon des stack pourries de ssl/tls pour éclairer la situation.
L'abandon de http est pour moi une erreur profonde qui exclu de fait du monde, beaucoup de monde et pousse à la poubelle du matos.
Le https-only everywhere est d'après moi une bêtise et oui quand on décide à ma place de ce qui est mieux pour moi j'ose dire que ce qui est bon pour certains ne l'est pas forcément pour tout le monde.
J'ai marqué dans mon 1er message "un fallback sur http" serait bienvenu et je maintiens cette position.
https ne marche pas ? http marche ? "super*" !
ssh ne marche pas ? telnet marche ? "super*" !
dnssec ne marche pas ? dns marche ? "super*" !
wpa-psk ne marche pas ? wifi open marche ? "super*" !
etc.
= super je peux encore faire des choses, ça peut aussi se faire hacker. J'ai une vielle bagnole sans abs, sans airbag, sans clim, sans radar de recul, sans boite auto mais elle me permet encore d'aller faire mes courses, d'aller chez le docteur, etc. je suis moins en sécurité dans cette vielle bagnole mais je n'ai pas les moyens d'en avoir une autre et elle rends encore sacrément service … c'est pareil pour bon nombre de publics avec un vieux photocopieur, un vieux serveur etc.
Et n'allez me faire dire que je suis contre tls and co … être en mesure de basculer sur un protocole non sécurisé ne dit pas que je suis contre ledit protocole sécurisé (et à jour).
Solidaire et humaniste c'est de ne pas se dire que le 1% ne vaut pas la peine qu'on se soucie d'eux … 1% c'est rien après tout ?
Posté par rycks .
En réponse au lien RIP HTTP.
Évalué à 7.
Dernière modification le 04 mai 2023 à 18:44.
Bon,
ça y est je suis un vieux con … alors je vais donner des exemple concrets d'endroits où c'est un problème:
maison de quartier, maison des jeunes, espace associatif où on bricole des vieux équipements mais c'est justement le but d'apprendre et de se former en dehors de toute école vu que le monde scolaire ne veut pas de nous (car nous sommes trop vieux, trop con, trop grand, trop chauves, trop maladaptés, ou pas assez …) et là oui un vieux HP avec iLO3 permet d'ouvrir des connaissances de dingue
intranet sans aucune connexion internet, maison d'arrêt (prison), centre de rééducation, certains "sous réseaux" de maisons familiales et rurales, intranet de certaines écoles, lieux contraints divers et variés
espaces clos non connectés aussi drôle que ça puisse être parfois même pour des raisons de sécurité (labo divers)
lieux de vies lointains (pas forcément au milieu de la brousse hein, ça peut être en haute montagne, au fond d'une vallée, ici ou ailleurs)
etc.
Et attention vieux matos ne veut pas dire vieux logiciels : et c'est bien le noeud du problème. Exemple : je fais des formations sur des HP équipés de iLO3 depuis un ordinateur tout à fait récent (quelques années à peine) lequel est équipé d'un firefox up-to-date …
J'espère simplement apporter un regard sur une réalité différente, n'oublions pas les autres, l'informatique aussi peut-être solidaire et humaniste.
Posté par rycks .
En réponse au lien RIP HTTP.
Évalué à 5.
Ça tombe bien SSL v1.0 n'a jamais été mis en œuvre ;-)
Haaaaaaa y en a au moins un qui a vu le troll :-)
Plus sérieusement, oui il est question d'un "logiciel" qui bride un "matériel" et le débat est sans fin.
Oui le constructeur devrait à minima ouvrir ses spec lorsqu’il retire son matériel de la liste du matériel qu'il "supporte", mais ça ne changera finalement pas grand-chose car les gens impactés par ces vieux matériels sont rarement en mesure de développer eux-mêmes des upgrades des logiciels embarqués. Mais ça serait déjà une grosse avancée.
Alors oui pour répondre à zenitram "je" peux conserver un firefox 1.0 sur un super vieux OS de l'époque. Mais "je" ne suis pas la cible de ma remarque.
La "cible" de ma remarque ce sont toutes ces personnes qui ne peuvent prétendre à du matériel moderne pour des questions idiotes qu'on appelle bien souvent "argent" (mais qui est plus largement l'accès à la technologie où je fait d'être dans un pays où il "faut faire avec") et qui se retrouvent donc avec des photocopieurs fonctionnels mais qui ont 20 ans + des switchs de l'époque, des routeurs délavés mais qui marchent et permettent de faire des choses … aussi incroyable que ça puisse être.
Je n'ose même pas parler d'une certaine forme de solidarité entre les bipèdes qui habitent la planète mais moi oui ça me déchire de constater que parce que c'est mieux pour vous on vous empêche d'accéder à l'interface d'admin d'un routeur tout simplement parce que sa stack https est obsolète. Alors que le même matériel accessible en http serait … utilisé et rendrait donc service.
Alors voilà, continuons à mettre à la décharge des matériels qui marchent mais qui ne sont plus pilotables. Monde absurde.
Un peu de lecture ? je crois avoir vu passer ça sur linuxfr il n'y a pas si longtemps:
Ça ne fait pas un certain écho ? Si vous ne voyez pas le lien alors je comprends que vous ne suiviez pas mon résonnement, je ne vous en veux pas pour autant :-)
Posté par rycks .
En réponse au lien RIP HTTP.
Évalué à 9.
J'ai déjà donné quelques avis sur le sujet, https partout tout le temps c'est quand même bien con !
C'est la porte ouverte à l'obsolescence par https !
Situation déjà existante que vous pouvez donc tester : prenez un serveur HP équipé de iLO3 et vous ne pourrez pas vous connecter sur l'interface de gestion à moins de ruser comme un sioux.
Alors oui https c'est super bien blablablabla mais c'est aussi la mort pour les vieux équipements dont la seule porte d'entrée est https (ssl 1.0) et plus le temps passe et plus ça concernera de matériels divers et variés.
Ça vaut pour des photocopieurs, des switchs, des serveurs, des routeurs, des AP wifi, etc. etc. etc.
Je reste donc militant pour avoir un fallback d'accès en http ! na !
C'est pas la 1ere fois que je me fais la même remarque, ce site n'a rien à voir avec le libre (ou alors parfois de manière très très lointaine) et n'a rien à faire ici …et la notion de "hacker" est à mon sens vraiment usurpée mais bon ça n'est que mon avis
Quand je vois des boites qui font -600k€ sur l'année j'ai pas trop envie de dire que c'est à cause de l'intermédiaire de paiement que ça ne marche pas.
Il me semble que ça aurait été plus transparent/sérieux de dire "notre business modèle ne tient pas, nous avons engloutis tous les sous qu'on nous a prêté, merci le PGE, au revoir".
Ha ben voilà,
ça fait des années que je cherche à comprendre la raison pour laquelle ils "codent" leur spam reason … merci de me dire que c'est décodable, j'avais finis par classer ça dans la liste des choses idiotes …
Bon, je prêche pour "ma" paroisse mais d'expérience ton auto entrepreneur aura besoin de "bricoles" au gréé des évolutions de son activité et donc autant partir sur un outil au périmètre assez vaste …
C'est super drôle d'arriver sur un site qui se revendique "Le courrier du hacker, la newsletter du Logiciel Libre et de l'Open Source" et de voir dans la section sysadmin
" Cloudfront : sécuriser votre infrastructure avec un WAF " qui est plein focus sur le titre du site :-)
J'ai osé cliqué dessus en me disant qu'il serait pas con d'aller expliquer à l'auteur qu'un firewall applicatif n'est acceptable au sens "libre" que s'il est auto-hébergé et que cloudfront à ma connaissance n'était pas trop dans cette optique … mais j'étais loin d'imaginer que le lien pointait sur un article encore plus gros "Comment configurer un WAF sur un CloudFront pour sécuriser une infrastructure AWS ?"
Alors bon, pardon hein mais j'aurais du regarder ça hier, un vendredi ça passe mais pas plus
Alors,
suite à vos remarques et mails reçus échangés, j'ai un peu chamboulé le site obapi.org pour rester à l'expression de l'idée et une sorte de "démonstration" pour ne pas m'enliser dans une sorte d'implémentation qui nuirait à l'objectif du projet.
Liorel, je suis 100% d'accord mais je cherche toujours ne serait-ce que le 1er "compétiteur" sur ce standard auquel j'aimerais me conformer et pour lequel j'aimerais faire la promotion …
Parceque-moi toutes les factures fournisseurs que je vois passer listent précisément tous les trucs qui sont achetés … oui j'ai pris une facture de tel comme exemple mais regarde une facture de ton magasin de matériel de bricolage, de fournitures etc.
Moi je veux bien que la banque sache que j'ai dépensé 2000€ chez le roi du merlin mais je n'ai pas forcément envie qu'il sache précisément ce que j'ai acheté, tu vois la fuite de données au passage et les conséquences ?
Allez, une facture d'un hébergeur de serveurs en trois lettres, je n'ai pas forcément envie que mon banquier ait la liste de toutes les IP des serveurs que je loue …
Et je reste super soft, le contenu des factures c'est très très révélateur de beaucoup de choses, que ça soit au niveau pro ou au niveau perso.
(Je ne veux pas détourner le sujet mais j'ai la même réaction par rapport à la fin des tickets papiers et qu'on te propose d'envoyer par mail, allez hop le facteur sait maintenant ce qu'il y a dans ton caddie.)
Donc pardon d'avoir "flingué une solution sous excuse qu'un de tes fournisseur fait des conneries" mais mon exemple était pourris et tu t'es pris dedans :)
C'est intéressant comme manière de faire … ainsi le banquier qui savait que j'avais dépensé 19,99€ chez mon opérateur de téléphone "avant" sait maintenant aussi à qui j'ai téléphoné grâce à la partie détaillée de ma facture qu'il absorbe au vol.
Alors non, pour moi ce n'est pas du tout le modèle de société que je souhaite avoir.
Je veux pouvoir avoir mes factures chez moi (et d'une manière générale "mes documents" chez "moi") …
Par contre peut-être que e-bill est lié au fait que tous les fournisseurs respectent une API permettant aux banque de ne pas avoir à développer autant de "connecteurs" que de "fournisseurs" (ce qui semblerait assez évident vu que les banques n'aiment pas perdre du temps et donc de l'argent pour rien).
Depuis peu j'ai intégré un point important par rapport à ce point de vue.
Vous avez entendu parler des arnaques aux faux RIB sur les factures ? voici un truc qui arrive souvent : mr x se fait piquer son login/pass à sa boite mail. Le (méchant pirate) lui détourne les factures, remplace le rib du fournisseur par son rib de pirate et collecte le pognon. L'arnaque n'est découverte souvent que de longues semaines plus tard lorsque l'entreprise fait la relance des impayés.
Ça arrive bien plus souvent que vous ne croyez.
Solution alternative: indiquer au client qu'une facture est disponible sur votre serveur via son portail client … il vient télécharger l'original et vous êtes "sûr" que le document n'a pas été altéré par un tiers.
Il y a d'autres solutions pour éviter ça comme par exemple sceller le document mais ça demande à ce que l'utilisateur final fasse l'usage d'un lecteur de document compatible (au pif en pdf la visionneuse js ne le fait pas) … et sache détecter un document dont le certificat aurait été altéré … sauf que si le pirate est pas con au lieu de "casser" le scellement il va tout simplement livrer un pdf sans certificat et donc le client aura un pdf non scellé sans savoir que l'original l'était !
Une autre serait d'envoyer un deep-link dans le mail, mais là encore ça me dérange car les outlook/gmail et autres pré-téléchargent le document et donc aucune confidentialité dans l'affaire. Et ça rejoint un autre contre-argument pour la réception par mail : à moins d'avoir son serveur mail perso la réception des factures par mail est une catastrophe au niveau confidentialité des données … le facteur peut tout savoir.
Perso je continue d'envoyer mes factures (scellées) par mail à mes clients … mais … j'avoue que j'hésite de plus en plus à conserver cette approche.
C'est justement en pensant à eux que je me dis qu'on pourrait grandement leur simplifier la vie si - par exemple - tous les logiciels libres de facturations respectaient la même norme (pour commencer) …
Je vois bien proposer à cozy d'implémenter le client obapi et "voir" le résultat sur 5 ou 10 entreprises (fournisseurs) qui utilisent dolibarr par exemple :)
[^] # Re: Un gestionnaire de tickets, et il y a le choix
Posté par rycks . En réponse au journal Opportunité de réinventer la roue... et la gestion de tickets ?. Évalué à 3.
Attention à odoo: regardez le coût de maintenance et de mise à jour avant de faire votre choix (quelques recherches à ce sujet sur votre moteur de recherche préféré devrait vous donner des éléments d'information).
Nombre d'utilisateurs de odoo restent "coincés" sur des anciennes versions à cause des coûts de mise à jour / upgrade.
eric.linuxfr@sud-ouest.org
[^] # Re: Vision du monde ...
Posté par rycks . En réponse au lien RIP HTTP. Évalué à 5. Dernière modification le 05 mai 2023 à 10:12.
Et qui me conforte à penser que vous avez une vue très étroite du monde, la France n'est pas le centre du monde.
Le http/https imposé à l'ensemble des humains est un problème bien plus vaste.
Que chez toi dans ta France il te soit "interdit" d'utiliser une vieille r5 sur les routes officielles (mais que techniquement tu peux encore faire tourner pour peu d'avoir du carburant compatible) pourquoi pas … mais tu ne veux quand même pas rendre impossible son usage à un Malgache ? une Cambodgienne, un Thaï, une Mexicaine, un Péruvien ?
De même que monter à 3/4/5 sur une moto sans casque pour aller travailler sur le chantier.
Donc oui mon exemple de la voiture est tout a fait correct pour illustrer le problème.
C'est ça la réalité, rendre inaccessible un matériel informatique qui ne propose qu'un accès https (donc non pérenne) c'est empêcher son utilisation pour des raisons que je trouve absurdes.
Vraiment ouvrez les yeux et changez de nombril :-)
eric.linuxfr@sud-ouest.org
[^] # Re: Vision du monde ...
Posté par rycks . En réponse au lien RIP HTTP. Évalué à 10. Dernière modification le 04 mai 2023 à 22:42.
Mais relis moi … je demande à ce que http perdure, je ne demande pas à ce que tls1.0 soit accepté en 2050. Non je demande à ce qu'en 2050 je puisse encore me connecter à l'interface d'admin du photocopieur, du point d'accès wifi, de la console de gestion d'un serveur etc.
Je prends l'exemple de l'abandon des stack pourries de ssl/tls pour éclairer la situation.
L'abandon de http est pour moi une erreur profonde qui exclu de fait du monde, beaucoup de monde et pousse à la poubelle du matos.
Le https-only everywhere est d'après moi une bêtise et oui quand on décide à ma place de ce qui est mieux pour moi j'ose dire que ce qui est bon pour certains ne l'est pas forcément pour tout le monde.
J'ai marqué dans mon 1er message "un fallback sur http" serait bienvenu et je maintiens cette position.
etc.
= super je peux encore faire des choses, ça peut aussi se faire hacker. J'ai une vielle bagnole sans abs, sans airbag, sans clim, sans radar de recul, sans boite auto mais elle me permet encore d'aller faire mes courses, d'aller chez le docteur, etc. je suis moins en sécurité dans cette vielle bagnole mais je n'ai pas les moyens d'en avoir une autre et elle rends encore sacrément service … c'est pareil pour bon nombre de publics avec un vieux photocopieur, un vieux serveur etc.
Et n'allez me faire dire que je suis contre tls and co … être en mesure de basculer sur un protocole non sécurisé ne dit pas que je suis contre ledit protocole sécurisé (et à jour).
Solidaire et humaniste c'est de ne pas se dire que le 1% ne vaut pas la peine qu'on se soucie d'eux … 1% c'est rien après tout ?
eric.linuxfr@sud-ouest.org
[^] # Re: Moué ben perso je pense que http devrait survivre !
Posté par rycks . En réponse au lien RIP HTTP. Évalué à 7.
Belle contradiction dans deux paragraphes qui se suivent:
ok donc le firefox obsolète pourra se connecter avec le vieux ssl du matos
et voilà : comment faire donc avec ton linux à jour pour te connecter sur un équipement dont le ssl n'est plus accepté par ton linux à jour ?
Et une projection à + 10 ans ?
eric.linuxfr@sud-ouest.org
# Vision du monde ...
Posté par rycks . En réponse au lien RIP HTTP. Évalué à 7. Dernière modification le 04 mai 2023 à 18:44.
Bon,
ça y est je suis un vieux con … alors je vais donner des exemple concrets d'endroits où c'est un problème:
Et attention vieux matos ne veut pas dire vieux logiciels : et c'est bien le noeud du problème. Exemple : je fais des formations sur des HP équipés de iLO3 depuis un ordinateur tout à fait récent (quelques années à peine) lequel est équipé d'un firefox up-to-date …
J'espère simplement apporter un regard sur une réalité différente, n'oublions pas les autres, l'informatique aussi peut-être solidaire et humaniste.
eric.linuxfr@sud-ouest.org
[^] # Re: Moué ben perso je pense que http devrait survivre !
Posté par rycks . En réponse au lien RIP HTTP. Évalué à 5.
Haaaaaaa y en a au moins un qui a vu le troll :-)
Plus sérieusement, oui il est question d'un "logiciel" qui bride un "matériel" et le débat est sans fin.
Oui le constructeur devrait à minima ouvrir ses spec lorsqu’il retire son matériel de la liste du matériel qu'il "supporte", mais ça ne changera finalement pas grand-chose car les gens impactés par ces vieux matériels sont rarement en mesure de développer eux-mêmes des upgrades des logiciels embarqués. Mais ça serait déjà une grosse avancée.
Alors oui pour répondre à zenitram "je" peux conserver un firefox 1.0 sur un super vieux OS de l'époque. Mais "je" ne suis pas la cible de ma remarque.
La "cible" de ma remarque ce sont toutes ces personnes qui ne peuvent prétendre à du matériel moderne pour des questions idiotes qu'on appelle bien souvent "argent" (mais qui est plus largement l'accès à la technologie où je fait d'être dans un pays où il "faut faire avec") et qui se retrouvent donc avec des photocopieurs fonctionnels mais qui ont 20 ans + des switchs de l'époque, des routeurs délavés mais qui marchent et permettent de faire des choses … aussi incroyable que ça puisse être.
Je n'ose même pas parler d'une certaine forme de solidarité entre les bipèdes qui habitent la planète mais moi oui ça me déchire de constater que parce que c'est mieux pour vous on vous empêche d'accéder à l'interface d'admin d'un routeur tout simplement parce que sa stack https est obsolète. Alors que le même matériel accessible en http serait … utilisé et rendrait donc service.
Alors voilà, continuons à mettre à la décharge des matériels qui marchent mais qui ne sont plus pilotables. Monde absurde.
Un peu de lecture ? je crois avoir vu passer ça sur linuxfr il n'y a pas si longtemps:
https://linuxfr.org/users/olivedeparis/liens/politique-de-l-absurde-le-numerique-et-l-acces-aux-droits-sociaux
Ça ne fait pas un certain écho ? Si vous ne voyez pas le lien alors je comprends que vous ne suiviez pas mon résonnement, je ne vous en veux pas pour autant :-)
eric.linuxfr@sud-ouest.org
# Moué ben perso je pense que http devrait survivre !
Posté par rycks . En réponse au lien RIP HTTP. Évalué à 9.
J'ai déjà donné quelques avis sur le sujet, https partout tout le temps c'est quand même bien con !
C'est la porte ouverte à l'obsolescence par https !
Situation déjà existante que vous pouvez donc tester : prenez un serveur HP équipé de iLO3 et vous ne pourrez pas vous connecter sur l'interface de gestion à moins de ruser comme un sioux.
Alors oui https c'est super bien blablablabla mais c'est aussi la mort pour les vieux équipements dont la seule porte d'entrée est https (ssl 1.0) et plus le temps passe et plus ça concernera de matériels divers et variés.
Ça vaut pour des photocopieurs, des switchs, des serveurs, des routeurs, des AP wifi, etc. etc. etc.
Je reste donc militant pour avoir un fallback d'accès en http ! na !
eric.linuxfr@sud-ouest.org
[^] # Re: Coopératives et intégrateurs
Posté par rycks . En réponse au lien Éleveurs enchaînés : "Je veux sortir du monde agricole mafieux" . Évalué à 3. Dernière modification le 26 avril 2023 à 18:11.
Voir la série / documentaire "Jeux d’influence : les Combattantes" sur Arte …
eric.linuxfr@sud-ouest.org
# Bravo !
Posté par rycks . En réponse au lien The GTK+3 port of GIMP is officially finished - @zemarmot. Évalué à 7.
Rien de plus à dire, quel engagement, pugnacité !
Bravo … et merci
eric.linuxfr@sud-ouest.org
[^] # Re: Titre ?
Posté par rycks . En réponse au lien Le Courrier du hacker (n°217) - pérennité du logiciel libre. Évalué à 2.
C'est pas la 1ere fois que je me fais la même remarque, ce site n'a rien à voir avec le libre (ou alors parfois de manière très très lointaine) et n'a rien à faire ici …et la notion de "hacker" est à mon sens vraiment usurpée mais bon ça n'est que mon avis
eric.linuxfr@sud-ouest.org
# moué ... mangopay c'est un peu facile non ?
Posté par rycks . En réponse au lien uTip annonce aujourd'hui qu'ils ferment demain. Évalué à 10.
Dites,
regardez un peu les chiffres (https://www.pappers.fr/entreprise/utip-827896895) et dites moi si c'est vraiment mangopay qui a tué cette boite ?
Quand je vois des boites qui font -600k€ sur l'année j'ai pas trop envie de dire que c'est à cause de l'intermédiaire de paiement que ça ne marche pas.
Il me semble que ça aurait été plus transparent/sérieux de dire "notre business modèle ne tient pas, nous avons engloutis tous les sous qu'on nous a prêté, merci le PGE, au revoir".
eric.linuxfr@sud-ouest.org
# Et ça détecte les poissons ?
Posté par rycks . En réponse à la dépêche L'IA pour lutter contre les fausses nouvelles ou infox. Évalué à 7.
eric.linuxfr@sud-ouest.org
# Enfin !
Posté par rycks . En réponse au journal Contournement de mesures de protection et intéropérabilité. Évalué à 4.
Ha ben voilà,
ça fait des années que je cherche à comprendre la raison pour laquelle ils "codent" leur spam reason … merci de me dire que c'est décodable, j'avais finis par classer ça dans la liste des choses idiotes …
eric.linuxfr@sud-ouest.org
[^] # Re: Rien de bien grave
Posté par rycks . En réponse au lien Silicon Valley Bank en faillite. Évalué à 7.
Et puisque "même" notre ministre se sent obligé de dire que tout est sous contrôle c'est que vraiment tout est sous contrôle.
eric.linuxfr@sud-ouest.org
# waitpid until vendredi bordel
Posté par rycks . En réponse au journal 50 mauvais conseils de codage pour développeur C++. Évalué à 8.
Tout est dans le sujet !
eric.linuxfr@sud-ouest.org
# 8 ans ...
Posté par rycks . En réponse au message Qu'est devenu Lolix v2?. Évalué à 4.
C'était il y a un bail tout de même … et sinon j'ai ça comme lien vers le dépot moi :
https://gitlab.com/rodo/lolyx
eric.linuxfr@sud-ouest.org
# dolibarr sans aucun doute :)
Posté par rycks . En réponse au message logiciel gestion client libre/gratuit?. Évalué à 5.
Bon, je prêche pour "ma" paroisse mais d'expérience ton auto entrepreneur aura besoin de "bricoles" au gréé des évolutions de son activité et donc autant partir sur un outil au périmètre assez vaste …
Ça se télécharge et s'auto-héberge sans soucis.
eric.linuxfr@sud-ouest.org
# Blague ?
Posté par rycks . En réponse au lien Le Courrier du hacker (n°208) - plateformes privatives. Évalué à 4.
C'est super drôle d'arriver sur un site qui se revendique "Le courrier du hacker, la newsletter du Logiciel Libre et de l'Open Source" et de voir dans la section sysadmin
" Cloudfront : sécuriser votre infrastructure avec un WAF " qui est plein focus sur le titre du site :-)
J'ai osé cliqué dessus en me disant qu'il serait pas con d'aller expliquer à l'auteur qu'un firewall applicatif n'est acceptable au sens "libre" que s'il est auto-hébergé et que cloudfront à ma connaissance n'était pas trop dans cette optique … mais j'étais loin d'imaginer que le lien pointait sur un article encore plus gros "Comment configurer un WAF sur un CloudFront pour sécuriser une infrastructure AWS ?"
Alors bon, pardon hein mais j'aurais du regarder ça hier, un vendredi ça passe mais pas plus
eric.linuxfr@sud-ouest.org
# GLPI
Posté par rycks . En réponse au message Respect d'une PSSI. Évalué à 7.
Hello,
à mon avis il faut s'appuyer sur une solution industrielle libre et au top pour collecter tout ça : GLPI + FusionInventory !
eric.linuxfr@sud-ouest.org
# Actualisation du 7 janvier
Posté par rycks . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 3.
Alors,
suite à vos remarques et mails reçus échangés, j'ai un peu chamboulé le site obapi.org pour rester à l'expression de l'idée et une sorte de "démonstration" pour ne pas m'enliser dans une sorte d'implémentation qui nuirait à l'objectif du projet.
J'ai pris contact avec https://www.openapis.org/ pour voir s'ils ont un groupe de travail sur le sujet en espérant que si oui il soit plus avancé que https://github.com/OAI/sig-finance …
eric.linuxfr@sud-ouest.org
[^] # Re: Woob
Posté par rycks . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 3.
Liorel, je suis 100% d'accord mais je cherche toujours ne serait-ce que le 1er "compétiteur" sur ce standard auquel j'aimerais me conformer et pour lequel j'aimerais faire la promotion …
eric.linuxfr@sud-ouest.org
[^] # Re: En suisse...
Posté par rycks . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 9.
Heu Zenitram, tu peux regarder tes factures ?
Parceque-moi toutes les factures fournisseurs que je vois passer listent précisément tous les trucs qui sont achetés … oui j'ai pris une facture de tel comme exemple mais regarde une facture de ton magasin de matériel de bricolage, de fournitures etc.
Moi je veux bien que la banque sache que j'ai dépensé 2000€ chez le roi du merlin mais je n'ai pas forcément envie qu'il sache précisément ce que j'ai acheté, tu vois la fuite de données au passage et les conséquences ?
Allez, une facture d'un hébergeur de serveurs en trois lettres, je n'ai pas forcément envie que mon banquier ait la liste de toutes les IP des serveurs que je loue …
Et je reste super soft, le contenu des factures c'est très très révélateur de beaucoup de choses, que ça soit au niveau pro ou au niveau perso.
(Je ne veux pas détourner le sujet mais j'ai la même réaction par rapport à la fin des tickets papiers et qu'on te propose d'envoyer par mail, allez hop le facteur sait maintenant ce qu'il y a dans ton caddie.)
Donc pardon d'avoir "flingué une solution sous excuse qu'un de tes fournisseur fait des conneries" mais mon exemple était pourris et tu t'es pris dedans :)
eric.linuxfr@sud-ouest.org
[^] # Re: En suisse...
Posté par rycks . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 4.
C'est intéressant comme manière de faire … ainsi le banquier qui savait que j'avais dépensé 19,99€ chez mon opérateur de téléphone "avant" sait maintenant aussi à qui j'ai téléphoné grâce à la partie détaillée de ma facture qu'il absorbe au vol.
Alors non, pour moi ce n'est pas du tout le modèle de société que je souhaite avoir.
Je veux pouvoir avoir mes factures chez moi (et d'une manière générale "mes documents" chez "moi") …
Par contre peut-être que e-bill est lié au fait que tous les fournisseurs respectent une API permettant aux banque de ne pas avoir à développer autant de "connecteurs" que de "fournisseurs" (ce qui semblerait assez évident vu que les banques n'aiment pas perdre du temps et donc de l'argent pour rien).
Je vais aller voir tout ça : Merci pour l'info
eric.linuxfr@sud-ouest.org
[^] # Re: Et le Mail
Posté par rycks . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 10.
Depuis peu j'ai intégré un point important par rapport à ce point de vue.
Vous avez entendu parler des arnaques aux faux RIB sur les factures ? voici un truc qui arrive souvent : mr x se fait piquer son login/pass à sa boite mail. Le (méchant pirate) lui détourne les factures, remplace le rib du fournisseur par son rib de pirate et collecte le pognon. L'arnaque n'est découverte souvent que de longues semaines plus tard lorsque l'entreprise fait la relance des impayés.
Ça arrive bien plus souvent que vous ne croyez.
Solution alternative: indiquer au client qu'une facture est disponible sur votre serveur via son portail client … il vient télécharger l'original et vous êtes "sûr" que le document n'a pas été altéré par un tiers.
Il y a d'autres solutions pour éviter ça comme par exemple sceller le document mais ça demande à ce que l'utilisateur final fasse l'usage d'un lecteur de document compatible (au pif en pdf la visionneuse js ne le fait pas) … et sache détecter un document dont le certificat aurait été altéré … sauf que si le pirate est pas con au lieu de "casser" le scellement il va tout simplement livrer un pdf sans certificat et donc le client aura un pdf non scellé sans savoir que l'original l'était !
Une autre serait d'envoyer un deep-link dans le mail, mais là encore ça me dérange car les outlook/gmail et autres pré-téléchargent le document et donc aucune confidentialité dans l'affaire. Et ça rejoint un autre contre-argument pour la réception par mail : à moins d'avoir son serveur mail perso la réception des factures par mail est une catastrophe au niveau confidentialité des données … le facteur peut tout savoir.
Perso je continue d'envoyer mes factures (scellées) par mail à mes clients … mais … j'avoue que j'hésite de plus en plus à conserver cette approche.
eric.linuxfr@sud-ouest.org
[^] # Re: Woob
Posté par rycks . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 5.
C'est justement en pensant à eux que je me dis qu'on pourrait grandement leur simplifier la vie si - par exemple - tous les logiciels libres de facturations respectaient la même norme (pour commencer) …
Je vois bien proposer à cozy d'implémenter le client obapi et "voir" le résultat sur 5 ou 10 entreprises (fournisseurs) qui utilisent dolibarr par exemple :)
eric.linuxfr@sud-ouest.org