We should investigate if it's possible to log in with taskcluster auth if your front-end is local and the thServiceDomain is set to stage or prod.
Ah with Django 1.9+ we might be able to use the new `CSRF_TRUSTED_ORIGINS` to make this work: https://docs.djangoproject.com/en/1.9/ref/settings/#std:setting-CSRF_TRUSTED_ORIGINS
Ok so a few things would need resolving: 1) $httpProvider isn't sending any cookies when cross-domain, since `withCredentials` defaults to false, so needs overriding (eg `$httpProvider.defaults.withCredentials = true;`). 2) With that set, the request fails due to the current backend CORS policy not allowing credentials. This would need CORS_ALLOW_CREDENTIALS setting to true (https://github.com/ottoyiu/django-cors-headers#cors_allow_credentials). 3) With that fixed, the frontend still wouldn't have the CSRF token to set via the X-CSRFToken header, since the cookie from which it is fetched (`csrftoken`) can only be accessed from the API's origin. The solution here seems to be to return the token in the login view response, and store in sessionstorage/localstorage (in the frontend's origin) and then set manually in the $http calls. 4) Even with that fixed, we'd still hit the referrer check, so would have to whitelist via CSRF_TRUSTED_ORIGINS too On the plus side with this approach, we could (once released) switch to Django 1.11's session-tied csrf token: https://docs.djangoproject.com/en/1.11/ref/settings/#std:setting-CSRF_USE_SESSIONS ...and therefore skip the risk of a csrf cookie (subdomain and MITM issues).
I've figured out a way to do this using the webpack-dev-server proxy. The first part for enabling this will land in bug 1363722. After that, we need to: 1) Update to a newer webpack-dev-server that includes the fix for the security I reported (https://github.com/webpack/webpack-dev-server/issues/887) 2) Resolve the fact that stage/prod set the `secure` attribute on their cookies, which get ignored when proxied to a non-HTTPS localhost origin. This can be fixed via either: (a) using HTTPS for local development (pain due to self-signed certs etc) (b) stripping the secure attribute as part of proxying I've opened an upstream PR for (2b): https://github.com/nodejitsu/node-http-proxy/pull/1166
(In reply to Ed Morley [:emorley] from comment #3) > 1) Update to a newer webpack-dev-server that includes the fix for the > security I reported > (https://github.com/webpack/webpack-dev-server/issues/887) We're now on the newer version as of bug 1364010: https://github.com/mozilla/treeherder/commit/0c42d47c9d123a882668aae6f97716a81d2e85f5#diff-8ee2343978836a779dc9f8d6b794c3b2R6639 > I've opened an upstream PR for (2b): > https://github.com/nodejitsu/node-http-proxy/pull/1166 Sadly no reply to the PR yet.
(In reply to Ed Morley [:emorley] from comment #4) > Sadly no reply to the PR yet. Still no reply, sigh. Though the workaround can be added via the config in our repo if needed, like so: https://github.com/nodejitsu/node-http-proxy/pull/1166#issuecomment-328764776