Pour le moment je n'ai pas besoin de CDN et ça marche super bien avec l'offre "Domain Validation" de SSLS : http://www.ssls.com/. Il y a peut être un truc que je ne comprend pas mais pour moi, juste avec ça, ça marche super bien,
Le 21 juin 2014 14:12, Benjamin Guimberteau <b.guimbert...@gmail.com> a écrit : > Sinon j’ai découvert NameCheap il n’y a pas longtemps, chez qui je prend > mes certificats SSL maintenant. Le wildcard est à 94$ mais surtout le > premier prix c’est 9$ pour un domaine simple. > > après le choix ce fait suivant ce que fais ton application, multiple > tenant ou pas ? I18n grace aux sous domaines ? > > > https://www.namecheap.com/security/ssl-certificates/comodo/positivessl-wildcard.aspx > <https://www.namecheap.com/security/ssl-certificates/comodo/positivessl-wildcard.aspx?aff=69661> > -- > Benjamin Guimberteau > e-mail : b.guimbert...@gmail.com > skype : b.guimberteau > > Le 21 juin 2014 à 13:52:52, Thibaut Barrère (thibaut.barr...@gmail.com) a > écrit: > > 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 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 .
