Produits Entr'ouvert » Authentic 2

Pour récupérer l'IP à partir d'une socket :

+                if not hasattr(request, "META"):
+                    record.id = request.getpeername()[0]
+
+                else:
+                    record.ip = request.META.get('REMOTE_ADDR', self.DEFAULT_IP)

Bizarre que ce filtre soit actif sur un authentic-multitenant.

C'est ma config locale, elle peut ne pas tout à fait correspondre à ce qu'on a sur les serveurs. (mais la même erreur a été rencontrée via hobo sur les serveurs).

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

C'est ma config locale, elle peut ne pas tout à fait correspondre à ce qu'on a sur les serveurs. (mais la même erreur a été rencontrée via hobo sur les serveurs).

Ça dans un sens c'est plus logique, après le patch est là depuis le 5 mars je ne vois pas ce qui a changé récemment pour que ça arrive.

Benjamin Dauvergne a écrit :

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

C'est ma config locale, elle peut ne pas tout à fait correspondre à ce qu'on a sur les serveurs. (mais la même erreur a été rencontrée via hobo sur les serveurs).

Ça dans un sens c'est plus logique, après le patch est là depuis le 5 mars je ne vois pas ce qui a changé récemment pour que ça arrive.

Je vois que sur hobo c'est aussi sur du devinst par sur un vrai serveur.

Côté hobo c'est sur une installation serveur (dans le ticket rencontré à GL, rencontré aussi hier côté imio).

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

Côté hobo c'est sur une installation serveur (dans le ticket rencontré à GL, rencontré aussi hier côté imio).

La trace que je vois sur #36017 c'est un runserver pas gunicorn ou uwsgi, on est d'accord ?

Oui, tout à fait, installation serveur, mais runserver temporairement exécuté sur cette base.

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

Oui, tout à fait, installation serveur, mais runserver temporairement exécuté sur cette base.

Ok j'ai trouvé le basehttpserver de Django se trouve dépendre de SocketServer.TcpServer qui pose l'objet socket retourné par socket.accept() dans self.request, et donc il se trouve que les logs venant de basehttpserver ne sont pas compatibles avec l'usage de request dans extra par les autres logs de Django; ça veut juste dire qu'il faudrait un traitement particulier du logger django.server pour reproduire la config de base de Django au niveau formatage et filtre :

# django/utils/log.py
 29     'formatters': {
 30         'django.server': {
 31             '()': 'django.utils.log.ServerFormatter',
 32             'format': '[%(server_time)s] %(message)s',
 33         }
 34     },

Au passage, maintenant en local je fais des trucs comme ça :

import logging.config

LOGGING_CONFIG = None # pour dire à django ne fais rien sur la config de log, c'est moi qui la gère de A à Z

LOGGING = {
    # définir une config from scratch comme je veux
}
logging.config.dictConfig(LOGGING)

Ça a selon moi l'immense avantage de permettre d'avoir toute la config de log immédiatement sous les yeux, et donc de redevenir compréhensible au lieu d'être aiguille dans botte de foin.

Emmanuel Cazenave a écrit :

Au passage, maintenant en local je fais des trucs comme ça :

[...]

Ça a selon moi l'immense avantage de permettre d'avoir toute la config de log immédiatement sous les yeux, et donc de redevenir compréhensible au lieu d'être aiguille dans botte de foin.

Ouaip mais ça n'empêche de devoir comprendre comment les softs utilisent logging, c'est dommage mais formateurs sont intimement liés par exemple au contenu des objets record (si tu as un formateur "%(host)s" mais que record.host n'existe pas ça va planter :/ au lieu d'afficher un contenu par défaut, ou "None" ou "-"); idem ici nos filtre supposent que record.request est tooujours un objet Request comme tout ce qui est loggé par défaut sur le logger django.request mais finalement ce n'est pas le cas pour le logger django.server.