Projet

Général

Profil

Development #26143

ne pas faire de cache des métadonnées locales

Ajouté par Frédéric Péters il y a plus de 5 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
05 septembre 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:

Description

Ça ne semble pas apporter grand chose mais un bug, #26141.


Fichiers


Demandes liées

Lié à Hobo - Bug #26141: "race condition" sur la création d'un tenant puis la mise à dispo de la clé SAMLFermé05 septembre 2018

Actions
Lié à django-mellon - Development #13881: ne pas utiliser les settings pour garder les métadonnées en cacheFermé07 novembre 2016

Actions

Historique

#1

Mis à jour par Frédéric Péters il y a plus de 5 ans

#2

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Lié à Bug #26141: "race condition" sur la création d'un tenant puis la mise à dispo de la clé SAML ajouté
#3

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Lié à Development #13881: ne pas utiliser les settings pour garder les métadonnées en cache ajouté
#4

Mis à jour par Thomas Noël il y a plus de 5 ans

Pourquoi pas, mais ça corrige pas vraiment le bogue, les metadata seront foireuses à un moment.

Je rapatrie ma question de #26141 :
Je me demande dans quel cadre un SP SAML peut avoir des metadata sans clé publique ?
Auquel cas je préférerais que mellon réponde 404 quand app_settings.PUBLIC_KEYS est vide.
Quitte à gérer un possible "settings.METADATA_WITHOUT_PUBLIC_KEYS_IS_OK_GO_GO_GO == True" dans les settings (et 404 si cet attribut est absent)

#5

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Statut changé de Solution proposée à Nouveau
  • Assigné à Frédéric Péters supprimé
  • Patch proposed changé de Oui à Non
#6

Mis à jour par Emmanuel Cazenave il y a plus de 5 ans

Thomas Noël a écrit :

Pourquoi pas, mais ça corrige pas vraiment le bogue, les metadata seront foireuses à un moment.

On passerait quand même de "foireuse de façon permanente (jusqu'à redémarrage dur serveur)" à "très brièvement foireuse", ça me semble être une avancée.

#7

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

  • Statut changé de Nouveau à Solution validée

Thomas Noël a écrit :

Pourquoi pas, mais ça corrige pas vraiment le bogue, les metadata seront foireuses à un moment.

Je rapatrie ma question de #26141 :
Je me demande dans quel cadre un SP SAML peut avoir des metadata sans clé publique ?

Quand il n'en a pas besoin :)

Auquel cas je préférerais que mellon réponde 404 quand app_settings.PUBLIC_KEYS est vide.
Quitte à gérer un possible "settings.METADATA_WITHOUT_PUBLIC_KEYS_IS_OK_GO_GO_GO == True" dans les settings (et 404 si cet attribut est absent)

On aurait juste besoin de pouvoir filer un template pour le répertoire du tenant à create_tenant(), histoire qu'il provisionne le contenu avant de renommer le répertoire.

#8

Mis à jour par Frédéric Péters il y a plus de 5 ans

Statut changé de Nouveau à Solution validée

Comme ce ticket partait sur autre chose, j'ai déplacé le patch vers #13881.

#9

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Statut changé de Solution validée à En cours

Je laisse la discussion se terminer ici si elle doit l'être.

#10

Mis à jour par Thomas Noël il y a plus de 5 ans

(pas plus de discussion de ma part)

#11

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Statut changé de En cours à Fermé
#12

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

Je serai pour fermer ce ticket et voir comment rendre l'initialisation d'un tenant plus atomique, dans cette partie:

            tenant_dir = os.path.join(tenant_base, hostname)
            if os.path.exists(tenant_dir):
                raise CommandError('tenant already exists')
            tenant_dir_tmp = os.path.join(
                    tenant_base, hostname + '__CREATION_IN_PROGRESS.invalid')
            try:
                os.mkdir(tenant_dir_tmp, 0755)
            except OSError as e:
                raise CommandError('cannot start tenant creation (%s)' % str(e))
            # tenant creation in database
            try:
                connection.set_schema_to_public()
                schema = TenantMiddleware.hostname2schema(hostname)
                tenant = get_tenant_model()(schema_name=schema, domain_url=hostname)
                if verbosity >= 1:
                    print
                    print self.style.NOTICE("=== Creating schema ") \
                        + self.style.SQL_TABLE(tenant.schema_name)
                with transaction.atomic():
                    tenant.create_schema(check_if_exists=True)
            except Exception as e:
                os.rmdir(tenant_dir_tmp)
                raise CommandError('tenant creation failed (%s)' % str(e))
            for folder in ('media', 'static', 'templates'):
                path = os.path.join(tenant_dir_tmp, folder)
                os.mkdir(path, 0755)
            # activate the tenant by creating its directory
            os.rename(tenant_dir_tmp, tenant_dir)

J'ai déjà signalé dans un autre ticket que la création du schéma devrait se faire dans une transaction (en cas d'échec sur l'initialisation du filesystem, on se retrouve avec un schéma en vrac, idem en cas de souci sur l'application des migrations, schéma incomplet). Actuellement c'est le répertoire qui fait foi quand à l'existence d'un tenant.

Formats disponibles : Atom PDF