Make webpack-dev-server work with authentication when using a local API instance



2 years ago
10 months ago


(Reporter: emorley, Assigned: emorley)


(Blocks: 1 bug)



(1 attachment)



2 years ago
When the Neutrino work landed it unfortunately regressed the full stack development workflow. Instead of being able to run `./ runserver` and start working immediately, one either has to:
* build the UI in full manually (like occurs in production)
* use `yarn start:local` which builds the UI but then watches/rebuilds as necessary

The latter approach is still much slower than using webpack-dev-server as normal, leaves the files in `dist/` which clutters up grep results, and requires hacky workarounds in the Neutrino configuration files.

Instead I've figured out a way that we can replace `start:local` with the standard webpack-dev-server that proxies requests and still works with authentication (which was the blocking for doing so before, since cross-domain didn't work).


2 years ago
Blocks: 1317752

Comment 1

2 years ago
I have this working, but am trying to work around bugs with webpack-dev-server and the proxy path globbing (to try and make requests to eg `/static/` and `/admin/` work too, and not just `/api/`), since I appear to be hitting the same issue as:

Even though the docs say this should be supported:



2 years ago
Blocks: 1364894
(In reply to Ed Morley [:emorley] from comment #0)
> * use `yarn start:local` which builds the UI but then watches/rebuilds as
> necessary

I'm finding in a local vagrant that `yarn start:local` does not appear to continue watching/rebuilding on its own, if I understand Ed's comment above correctly.

I am finding for each development edit, to see the result I have to manually delete my /dist, and do another `yarn start:local` to fully rebuild dist each time. Could be pilot error on my part though, if there's some trick I'm missing or isn't in the docs.

Comment 3

a year ago
Yeah that's expected at the moment (but also unrelated to this bug), Cameron asked about the same a few weeks ago. I've added a todo to the general "fix the fallout from moving to a mandatory UI build" bug (bug 1353014 comment 12) to track this.


a year ago
Blocks: 1416266

Comment 4

a year ago
Bug 1395356 will make this easier + regardless we might as well wait until it lands first to avoid conflicts.
Depends on: 1395356


10 months ago
Attachment #8974446 - Flags: review?(cdawson)
Comment on attachment 8974446 [details] [review]
Link to GitHub pull-request:

Nothing short of fantastic!  :)
Attachment #8974446 - Flags: review?(cdawson) → review+
Commit pushed to master at
Bug 1363722 - Allow login to work in all development workflows (#3534)

Previously it was not possible to test features that required an
authenticated user when:
* using `yarn start` with Vagrant (bug 1363722), which meant slower
  watch builds
* pointing the UI at the prod/stage API (bug 1317752), which was
  extremely limiting

Now login works in all environments, since the frontend no longer uses a
URL prefix, but instead webpack-dev-server proxies non-webpack URLs to
the chosen `BACKEND_DOMAIN` - avoiding cross-domain issues. Cookies are
rewritten to remove any `secure` directive (which is set on production),
so that they can still be read from HTTP localhost. The `Referer` has to
also be changed to stop Django's CSRF checks from rejecting request.

The slower "build into `dist` and watch" mode is therefore no longer
necessary, so `yarn start:local` instead invokes webpack-dev-server just
like `yarn start` - and the `local-watch.js` workaround has been

Support for the "publish to GitHub with hardcoded `SERVICE_DOMAIN`"
workflow has been dropped, since it was already rarely used and there is
no way to make it support login.

The API domain environment variable was renamed to `BACKEND_DOMAIN` to
avoid potential confusion given it no longer behaves the same as

NB: For full stack Vagrant workflows users must now connect to port
*5000* on localhost, not 8000.


10 months ago
Last Resolved: 10 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.