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 .
