2016-02-15 1 views
0

J'ai une application Django qui sert principalement sous domain.com, mais aussi sous d'autres domaines (principalement pour les tests). J'ai également un sous-domaine distinct qui sert le code client de l'application Web aux utilisateurs.CSRF échoue avec plusieurs domaines (pas des sous-domaines) desservis par l'application Django

Le domaine principal de l'API est api.domain.com et les applications sont en cours de déploiement à apps.domain.com. Les serveurs de transfert ne sont pas sous le même nom de domaine; ils vivent au stagingX.otherdomain.com. Ceci est hors de mon contrôle.

Le problème que j'ai est que je reçois des échecs CSRF lorsque je tente de se connecter à partir apps.domain.com:

Failed to load resource: the server responded with a status of 403 (OK) 
login error: "CSRF Failed: Referer checking failed - http://apps.domain.com/ does not match https://api.domain.com/." 

Il un monde simple, je voudrais simplement mettre CSRF_COOKIE_DOMAIN à *.domain.com et être fait. Cependant, cela détruit complètement ma capacité à mettre en place le code avant le déploiement, car l'accès direct à l'API au stagingX.otherdomain.com doit également fonctionner pour différents tests qui doivent être exécutés. Est-ce que quelqu'un peut m'éclairer sur comment exactement je devrais mettre cela en place? Je suis en train de ruiner le jour où j'ai décidé de déployer des applications sur un serveur séparé, mais le déploiement d'applications et le déploiement d'API doivent être séparés pour d'autres raisons ... cela me rend fou.

Merci d'avance.

- ÉDITÉ ajouter des informations supplémentaires -

Pour ce que ça vaut, je me sers de la protection des CORS ainsi. Il semble que je devrais peut-être utiliser une sorte d'en-tête CORS plutôt que CSRF dans ce cas, mais je ne comprends pas suffisamment le mécanisme CORS pour comprendre si c'est là que réside la solution. J'ai apps.domain.com en liste blanche, mais cela ne fonctionne pas sur la connexion et peut-être sur d'autres points de terminaison (ne peut pas passer le login pour vérifier les autres).

+0

À court terme, j'ai mis en place une authentification basée sur des jetons et CSRF-exempté le point de connexion, cela semble fonctionner mais ce n'est pas idéal. – seawolf

Répondre

2

Dans 1.9, le paramètre CSRF_TRUSTED_ORIGINS a été ajouté. Vous pouvez définir cette à une liste de (sous) domaines qui sont valides dans la vérification CSRF referrer:

CSRF_TRUSTED_ORIGINS = ['api.domain.com', 'apps.domain.com', 'stagingX.otherdomain.com'] 

configurer dans le fichier des paramètres pour api.domain.com, et il acceptera les demandes POST de tous les 3 domaines.

+0

Malheureusement, je ne suis pas en mesure d'exécuter 1.9. Cela fonctionne sur Google App Engine avec DjangoAppEngine pour utiliser le datastore au lieu de SQL comme backend de données, et DAE n'est pas encore à 1.9. – seawolf