Re: [RailsFr] Re: Faites vous toutes les pages d'un site HTTPS ou une partie?

2014-06-22 Par sujet Guirec Corbel
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  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
> 
> --
> 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  a
> écrit :
>
>  100$ ici: https://dnsimple.com/plans
>
> Envoyé de mon iPhone
>
> Le 21 juin 2014 à 13:40, Olivier El Mekki  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  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 

Re: [RailsFr] Re: Faites vous toutes les pages d'un site HTTPS ou une partie?

2014-06-21 Par sujet Benjamin Guimberteau
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
-- 
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  a écrit :

100$ ici: https://dnsimple.com/plans

Envoyé de mon iPhone

Le 21 juin 2014 à 13:40, Olivier El Mekki  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  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 abon

Re: [RailsFr] Re: Faites vous toutes les pages d'un site HTTPS ou une partie?

2014-06-21 Par sujet Thibaut Barrère
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  a écrit :
> 
> 100$ ici: https://dnsimple.com/plans
> 
> Envoyé de mon iPhone
> 
>> Le 21 juin 2014 à 13:40, Olivier El Mekki  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  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

Re: [RailsFr] Re: Faites vous toutes les pages d'un site HTTPS ou une partie?

2014-06-21 Par sujet Thibaut Barrère
100$ ici: https://dnsimple.com/plans

Envoyé de mon iPhone

> Le 21 juin 2014 à 13:40, Olivier El Mekki  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  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...@

Re: [RailsFr] Re: Faites vous toutes les pages d'un site HTTPS ou une partie?

2014-06-21 Par sujet Olivier El Mekki
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 > 
> 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 plus d'options, visitez le site https://groups.google.com/d/optout .


Re: [RailsFr] Re: Faites vous toutes les pages d'un site HTTPS ou une partie?

2014-06-21 Par sujet Thibaut Barrère
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  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 
> 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 .