mais attention ce n'est probablement pas exactement le même type de certificat etc aussi, vérifiez avant!
Envoyé de mon iPhone > Le 21 juin 2014 à 13:46, Thibaut Barrère <thibaut.barr...@gmail.com> a écrit : > > 100$ ici: https://dnsimple.com/plans > > Envoyé de mon iPhone > >> Le 21 juin 2014 à 13:40, Olivier El Mekki <oelme...@gmail.com> a écrit : >> >> Wow, ça vaut le coup. Les wildcards comodo commencent à $330 [1]. >> >> Dommage qu'il faille héberger le nom de domaine chez eux pour avoir >> cette offre. >> >> [1] http://ssl.comodo.com/wildcard-ssl-certificates.php >> >> >>> On Saturday, June 21, 2014 1:27:37 PM UTC+2, Thibaut Barrère wrote: >>> Moi je fais full ssl. J'ai pris du wild card comodo via dnsimple, ça doit >>> être ~100$ de tête. >>> >>> Envoyé de mon iPhone >>> >>>> Le 21 juin 2014 à 12:40, Olivier El Mekki <oelm...@gmail.com> a écrit : >>>> >>>> Hello, >>>> >>>> J'ai pour l'instant une seule page en https (la page de paiement qui >>>> utilise stripe), mais je me pose la même question. Voici les avantages >>>> et inconvénients que j'ai trouvé dans les deux cas. >>>> >>>> >>>> Utiliser du tout ssl >>>> -------------------- >>>> >>>> C'est probablement plus cohérent et si tu as un certificat, c'est >>>> dommage de ne pas l'utiliser. Il y a un certain coût en performance pour >>>> l'utilisation de ssl, mais il est relativement négligeable (avec une >>>> configuration ssl correct, par exemple en n'oubliant d'inclure les >>>> certificats parents dans ton certificat pour minimiser le nombre de >>>> requêtes). >>>> >>>> Le principal problème que je vois est le coût. Si tu veux faire du tout >>>> ssl, il va te falloir un certificat wildcard, parce qu'un jour où >>>> l'autre, tu vas utiliser un cdn (si ce n'est pas le cas dès le début). >>>> Ça rajoute directement plusieurs centaines d'euros au coût de ton >>>> certificat. >>>> >>>> Si tu as une api, la latence peut également être non négligeable (si un >>>> service repose sur un service, le second doit avoir des performances >>>> exemplaires). À voir au cas par cas les besoins de performance des apis. >>>> >>>> >>>> Utiliser une seule page en ssl >>>> ------------------------------ >>>> >>>> Dans le cas d'une page de paiement, tu peux réussir à te débrouiller >>>> avec un certificat single domain. Ces pages sont généralement épurées. >>>> Si tu venais à utiliser un cdn, tu pourrais donc inclure ton css >>>> directement dans la page. >>>> >>>> Cela pose néanmoins des problèmes au développement. Déjà, il faut que tu >>>> fasses tourner deux process, en dev (un normal et un ssl), en utilisant >>>> god, un procfile ou whatever. J'utilise personnellement god, ça me >>>> permet de démarrer le tout en une commande quand j'ai besoin des pages >>>> ssl, mais je ne peux plus par exemple mettre des `binding.pry`. C'est >>>> surement contournable si je prennais le temps d'y réfléchir, mais c'est >>>> juste suffisamment ennuyeux pour être remarquable. >>>> >>>> Ensuite, il y a le problème des tests d'intégration. Je n'ai pas trouvé >>>> pour l'instant de moyen propre de faire switcher capybara/poltergeist >>>> entre ssl et non ssl. Du coup, j'ai dû mettre ... des conditions qui >>>> testent si on est en environment test au moment de générer les liens qui >>>> changent le protocol (et ne pas le changer en env de test), ce qui est >>>> absolument horrible (si quelqu'un a une autre idée, je suis prenneur). >>>> >>>> >>>> >>>> En conclusion, je dirais : fais du tout ssl si ta boite est riche :) (et >>>> prend en compte le cas de la latence des apis) >>>> >>>> >>>>> On Saturday, June 21, 2014 7:31:38 AM UTC+2, Guirec Corbel wrote: >>>>> Salut, >>>>> >>>>> J'ai un site avec une partie sécurisé et je me demandais si ça vallait la >>>>> peine de faire certaines parties non sécurisé et s'il y a des intérets à >>>>> ça. Le boulot que ça rajoute serait de définir quels sont les pages >>>>> sécurisées ou non. D'après ce que je vois, les navigateurs mettent en >>>>> cache les parties sécurisées aussi. >>>>> >>>>> Quel est votre opinion? >>>>> >>>>> Merci! >>>> >>>> -- >>>> -- >>>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de >>>> Google Groups. >>>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >>>> rails...@googlegroups.com >>>> Pour résilier votre abonnement envoyez un e-mail à l'adresse >>>> railsfrance...@googlegroups.com >>>> --- >>>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes >>>> "Railsfrance". >>>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >>>> concernant, envoyez un e-mail à l'adresse railsfrance...@googlegroups.com. >>>> Pour obtenir davantage d'options, consultez la page >>>> https://groups.google.com/d/optout. >> >> -- >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de >> Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> railsfrance@googlegroups.com >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> railsfrance-unsubscr...@googlegroups.com >> --- >> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes >> "Railsfrance". >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >> concernant, envoyez un e-mail à l'adresse >> railsfrance+unsubscr...@googlegroups.com. >> Pour obtenir davantage d'options, consultez la page >> https://groups.google.com/d/optout. -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
