-
Les gens, si vous développez des libs qui font du résal, et que vous supportez TLS, merci **D’ARRÊTER** de masquer 99.99% des options de configuration bas niveau de TLS pour ne laisser qu’un pov’ booléen « verify: true|false » dans votre API… 😱Permalink On twitter.com
♻️ 2 Retweets
❤️ 8 Favorites
Mood 0
-
Typiquement, arrêtez de bouffer violemment le verify_callback, qui permet de gérer finement les certificats sans pour autant devoir débrayer toute la vérification TLS… 🙏Permalink On twitter.com
❤️ 1 Favorite
Mood +2 🙂
-
Là j’ai Net::HTTP qui propage bien l’info, mais HTTParty la masque par les méthodes de classe (on doit pouvoir bricoler un truc avec les méthodes d’instance) et SwiftClient qui rebouffe toutes les options de HTTParty à nouveau… 2 couches à bidouiller à mort pour pouvoir vérifierPermalink On twitter.com
Mood 0
-
un certificat auto-signé et éviter lePermalink On twitter.com
verify: falseà la con quoi… 😱
Mood -1 🙁
-
Ici ruby-doc.org/stdlib-2.6.2/libdoc/net/http/rdoc/Net/HTTP.html#verify_callback n’est pas accessible via rubydoc.info/github/jnunemaker/httparty/HTTParty#get-class_method et donc encore moins ici github.com/cozy/swift_client/blob/master/lib/swift_client.rb#L246 😱Permalink On twitter.com
Mood +1 🙂
-
Quand vous développez un code, propagez le maximum d’options de configuration de vos bibliothèques d’en dessous à la couche du dessus pour ne pas fermer de portes à ceux qui vont vouloir utiliser votre propre bibliothèque. Encore moins quand on parle de choses aussi générique quePermalink On twitter.com
❤️ 1 Favorite
Mood 0
-
du HTTP/TLS… 🙏On twitter.com
Mood +2 🙂