Produits Entr'ouvert » Authentic 2

Même sans migration on peut juste ne plus afficher le champ texte, je pense.

Dans le clean, on pourrait râler quand il reste les deux possibilités :

if self.metadata_path and self.metadata_file:
    raise ValidationError('faut choisir dans la vie (merci d'effacer metadata_path)')

Aussi, peut-être que "upload_to" pourrait être du genre "saml_authenticator", voire une fonction qui nomme bien l'affaire :

def metadata_directory_path(instance, filename):
    return 'saml_authenticator_{0}/metadata.xml'.format(instance.id)

Ici comme ailleurs j'aurai une préférence pour avoir tout dans le modèle (même si en front c'est un champs fichier), donc un TextField (c'est fait comme ça sur LibertyProvider coté IdP et je ne le regreete pas), on se fout un peu du nom du fichier des métadonnées ensuite les media d'authentic ne doivent pas êtres exposés au public donc faudrait en plus une vue de téléchargement de toute façon.

Par contre ce serait bien de considérer l'entity_id issue du fichier comme l'URL et de l'ajouter aussi si on a un fort pressentiment que c'est une URL de métadonnées (genre on fait un GET et ça renvoit des métadonnées, avec un timeout à 5 secondes). Au niveau django-mellon on peut déclarer les deux et ça se mettra à jour, tout seul. Autant pour les ADFS on premise c'est rare que ça bouge mais pour AzureAD possible que ça fasse du roll-over de clé.

Benjamin Dauvergne a écrit :

Ici comme ailleurs j'aurai une préférence pour avoir tout dans le modèle

Pourquoi ?

(même si en front c'est un champs fichier), donc un TextField

Le TextField existe, il n'y a donc rien à faire, je ne vais pas bricoler un champ fichier alimenté par un TextField pour s'éviter le copier coller nécessaire à remplir le TextField directement.

Ici comme ailleurs il s'agit de simplifier à la fois l'interface de configuration et le code, je ne produirai rien qui n'aille pas dans ce sens.

les media d'authentic ne doivent pas êtres exposés au public donc faudrait en plus une vue de téléchargement de toute façon.

Bonne remarque mais il y a juste à avoir un uuid aléatoire dans le chemin vers le fichier, c'est classique.

Par contre ce serait bien de considérer l'entity_id issue du fichier comme l'URL

Je te laisse ouvrir le ticket correspondant.

Valentin Deniaud a écrit :

Pourquoi ?

C'est mieux d'avoir la configuration à un seul endroit, en base, qu'à plein d'endroits, ça enlève un accès disque inutile et ça ne coûte rien.

(même si en front c'est un champs fichier), donc un TextField

Le TextField existe, il n'y a donc rien à faire, je ne vais pas bricoler un champ fichier alimenté par un TextField pour s'éviter le copier coller nécessaire à remplir le TextField directement.

Ça ne me dérange pas.

Ici comme ailleurs il s'agit de simplifier à la fois l'interface de configuration et le code, je ne produirai rien qui n'aille pas dans ce sens.

Je parle du stockage, l'interface est très bien.

les media d'authentic ne doivent pas êtres exposés au public donc faudrait en plus une vue de téléchargement de toute façon.

Bonne remarque mais il y a juste à avoir un uuid aléatoire dans le chemin vers le fichier, c'est classique.

Pas exposé, c'est pas exposé, autant éviter un trou de sécurité plus tard quand on exposera une clé RSA stockée dans un fichier parce qu'on a pris une mauvaise habitude.

Par contre ce serait bien de considérer l'entity_id issue du fichier comme l'URL

Je te laisse ouvrir le ticket correspondant.

Ok.

Je ne comprends plus ce qu'il faut faire, il y a déjà un TextField (SAMLAuthenticator.metadata).

Ce qui justifiait ce ticket c'est que le procédé « avoir metadata.xml, l'ouvrir, le copier, le coller dans le formulaire » paraissait moins bien que « avoir metadata.xml, l'uploader ».

Dans ce cas je propose de simplement supprimer le champ chemin qui est effectivement une source d'erreur potentielle, et juste recopier les contenu dans le champ contenu XML. Le souci c'est surtout le champ texte qui contient un chemin sur le disque local, pas l'absence d'un champ fichier.

PS:

Ce qui justifiait ce ticket c'est que le procédé « avoir metadata.xml, l'ouvrir, le copier, le coller dans le formulaire » paraissait moins bien que « avoir metadata.xml, l'uploader ».

Il me semble que le souci c'était que quelqu'un (Fred/) a remarqué qu'il y avait des chemins vers des fichiers locaux, il a pu penser que c'était la seule façon de faire.