Produits Entr'ouvert » Passerelle

Ça m'irait bien qu'on standardise cette méthode requests_options au niveau de la classe de base (et avec des getattr parce que quand même pas pour ajouter ca_bundle et keystore partout).

Et en fait la partie ca_bundle, ça m'irait bien que ça ne se retrouve pas partout, qu'on puisse gérer ça dans des options globales à Passerelle.

Bref, si on peut se donner ici ce temps, c'est cool, sinon je créerai des tickets pour évoluer vers ça.

Mixin !! Enfin plutôt un modèle abstrait ResourceWithCertificates :)

Frédéric Péters a écrit :

Ça m'irait bien qu'on standardise cette méthode requests_options au niveau de la classe de base (et avec des getattr parce que quand même pas pour ajouter ca_bundle et keystore partout).

Yep. Je prépare ça.

Et en fait la partie ca_bundle, ça m'irait bien que ça ne se retrouve pas partout, qu'on puisse gérer ça dans des options globales à Passerelle.

Nope, car il s'agit ici de dire "cette instance de connecteur accepte que le certif du serveur en face provienne de telle CA (et pas d'une autre)". L'idée est donc de permettre une authentification plus forte du serveur en face, et pas seulement d'ajouter des CA à un bundle système par défaut qu'on ne connait pas. C'est bien dans la config de l'instance du connecteur que ça a lieu, à côté de la définition d'un éventuel certif client.

Mixin !! Enfin plutôt un modèle abstrait ResourceWithCertificates :)

Ouaip.

Nope, car il s'agit ici de dire "cette instance de connecteur accepte que le certif du serveur en face provienne de telle CA (et pas d'une autre)".

J'ai l'impression que le nom n'est pas terrible; exprimé comme ici le souhait me semble plutôt relever du certifcate pinning. (...) et que la réalité au final serait un mix des deux parce qu'en face on se trouve avec un certicat signé par une autorité non reconnue / autosigné mais on veut s'assurer qu'il ne change pas. (je n'ai pas cherché l'adresse du serveur qu'on a en face ici).

(et question vocabulaire la documentation de python-requests qui propose juste "path to a CA bundle to use" n'aide pas).

Et à continuer à réfléchir sur une situation dont je n'ai pas le détail précis, je me mets à imaginer les possibilités suivantes, sans exposer cette option,

• si certificat pas reconnu
  • affichage d'un message proposant d'en voir les détails, de l'accepter pour l'avenir (comme un navigateur, comme un client ssh).
• si certificat reconnu
  • ajout dans un menu d'une action "pin certificate" qui limiterait à l'avenir les connexions au certificat présent.

Tout ça nous emmène sans doute trop loin.

Mixin...

Ouaip.

Perso avoir une grosse classe de base me va plutôt mieux.

Frédéric Péters a écrit :

Nope, car il s'agit ici de dire "cette instance de connecteur accepte que le certif du serveur en face provienne de telle CA (et pas d'une autre)".

J'ai l'impression que le nom n'est pas terrible; exprimé comme ici le souhait me semble plutôt relever du certifcate pinning. (...) et que la réalité au final serait un mix des deux parce qu'en face on se trouve avec un certicat signé par une autorité non reconnue / autosigné mais on veut s'assurer qu'il ne change pas. (je n'ai pas cherché l'adresse du serveur qu'on a en face ici).

Pour le CD80 on a en face un serveur avec un certificat de leur PKI. On veut donc vérifier la requête se fait sur une machine signée par eux, il suffit pour ça de faire un «verify=resource.ca_bundle.path» avec le bundle qu'ils nous ont fourni. Que le certif ne change pas n'est pas un enjeu, au contraire (ça expire, un certif) ; on veut juste vérifier qu'il est certifié par la collectivité.

documentation de python-requests qui propose juste "path to a CA bundle to use" n'aide pas

(perso, ca_bundle, je comprends immédiatement de quoi il s'agit)

Tout ça nous emmène sans doute trop loin.

Yep.

Mixin...

Ouaip.

Perso avoir une grosse classe de base me va plutôt mieux.

Je voyaix les mixin pour ajouter automatiquement les champs username/password, keystore ou ca_bundle dans une resource, sans avoir besoin de déclarer autre chose que ces classes à côté du BaseResource.

Copie d'écran ...

Qui m'éclaire sur le nom (ou c'est juste le matin), l'attribut devrait s'appeler trusted_certificate_authorities.

# - use login/pass authentication if resource.username and resource.password exist
# - use client side certificate if resource.keystore exists
# - use server certificate CA verification if resource.ca_bundle exists
# - disable CA verification if resource.verify exists

... exists and is set; dirais-je.

    logger = logging.getLogger('logged_requests')

Virer la partie logged_, vu le 0001.

0003_...

Et sur l'idée d'un mixin, paradoxalement trop de choses réunies; le travail dans 0002 qui fait un gros "Requests" me va bien, mais pour moi il pouvait s'accompagner de simples modifications par convention dans les classes des connecteurs. Ou alors diviser, HttpAuthMixin, ProxyMixin, SslMixin, etc. Et sur l'ordre des champs, mettre la classe Mixin après la classe BaseRessource ?

Est-ce qu'on déporterait pas le changement de comportement de request dans les mixin ? Genre avoir une méthode get_requests_kwargs(**kwargs) comme get_form_kwargs(**kwargs) dans les vues génériques Django ?

Bon après ce qui me gêne ça va être les cas ou username/password ne doit pas être utilisé en HTTP Basic, mais bon on verra le jour où ça arrive pour rendre le comportement débrayable (ça casse rien d'avoir un entête HTTP Basic qui ne sert pas, ce n'est juste pas bien propre).

... de façon plus explicite

Bien mais manque alors la migration username → basic_auth_username / password → basic_auth_password.

Ok.