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 <javascript:>> 
> 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 <javascript:>
> Pour résilier votre abonnement envoyez un e-mail à l'adresse 
> railsfrance...@googlegroups.com <javascript:>
> --- 
> 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 
> <javascript:>.
> 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 .

Répondre à