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 <[email protected]> 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 > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > --- > 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 > [email protected]. > 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 [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- 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 [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
