There are a few other things at play that will require more investigation at a future date:
- Why window.location.assign() or history.pushState() do not work
- If any other config or polyfills are needed with JSDOM
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
the next url comes from sign in via a query param, and needs to go to
the POST /webauthn/authenticate endpoint. That endpoint logs the user
in and returns the redirect to the browser, and will take the next from
the request query params to get there.
also moving the window mocks to beforeEach/afterEach ensures that
promise callbacks from previous tests aren't still associated in future
tests to ensure good test isolation.
unfortunately i couldn't get mocking location for a single js test to
work, but by changing the global config i was able to add some query
params that i can expect to be passed through. Don't love this at all
but not quite sure of a good way round this. I think we're not
practicing very good hygiene and best practices with our mocking and
it's really confounding me here.
https://jestjs.io/docs/en/configuration#testurl-string
Affects all DOM APIs that return information about
the URL, for example window.location.
Why:
We now have tests for setting/deleting cookies.
Tough-cookie, the library JSDOM uses for cookie
handling cookies doesn't allow setting cookies
with `domain=localhost`. This is correct by
RFC6265, the standard it follows, as domains must
have 2 or more `.`s in them.
The only way to set a cookie on `localhost` is to
leave out the `domain` attribute.
The code we are testing sets and deletes cookies
set on specific domains so using `localhost` is
out.
We also cannot just set/delete cookies on the
domains used as cookies are required to match the
domain of the current page.
The solution we are left with is to set the
current page to one from production and make sure
each cookie is set relative to that domain.
Note: this introduces `testURL` in isolation to be
sure it doesn't break any existing tests.
