LG-3474: Reference Acuant SDK as static resource from root

[aduth]

Why: To avoid unnecessary server processing

As a user, I don't want the document capture experience to take a long time to load, so that I can upload my images without being confronted by spinners

Implementation notes:

From what I've been able to tell, Acuant SDK does make an attempt to load additional assets from the loaded script's directory, at least for AcuantImageProcessingService.js.mem. This compiled binary is responsible for loading AcuantImageProcessingWorker, which does load from the current directory. As such, only these files are necessary to load as relative, which could at least avoid server handling AcuantJavascriptWebSdk.min.js (1MB) and AcuantImageProcessingService.js.mem (10KB).

The relevant code is minified in the Acuant SDK (even in the non-minified source file), but there is an expanded copy in the React source example:

• .wasm .js.mem file is located using locateFile (this code appears outdated. In Acuant v11.4, this .wasm file was substituted with .js.mem. See LG-3357: Upgrade Acuant SDK to v11.4.1 #4128. This is obfuscated in the current version source file).
• locateFile appends given path argument to scriptDirectory
• scriptDirectory is set from document.currentScript.src

Open questions:

• Is it worth it? The original ticket would have use measuring the exact benefit. It seems like we should want to not have Rails serve these files if possible? Assuming we're using a server like nginx to serve static files (needs clarity).
• Previously we would set the content type header for .js.mem file. This is no longer implemented. Locally, it falls back to text/plain, which at first glance does not appear to cause any problems.

[zachmargolis]

LGTM, we do serve the public/ directory via Nginx in prod currently, so this should work

[aduth]

One thing I should double-check here is whether this can work if we'd relied on the server to send CSP directives.

These:

identity-idp/app/controllers/acuant_sdk_controller.rb

Lines 15 to 18 in b702ae1

	SecureHeaders.append_content_security_policy_directives(
	request,
	script_src: ['\'unsafe-eval\''],
	)

[zachmargolis]

One thing I should double-check here is whether this can work if we'd relied on the server to send CSP directives.

We set our nginx headers here: https://github.com/18F/identity-devops/blob/master/kitchen/cookbooks/login_dot_gov/templates/default/nginx_server.conf.erb

I forget if the way CSP works is if we need to set the unsafe-eval on the HTML document that loads the JS, or on the JS file itself?

[jmhooper]

I forget if the way CSP works is if we need to set the unsafe-eval on the HTML document that loads the JS, or on the JS file itself?

You need it on the document. We set them on the JS in the SDK controller because Safari has some weird behavior if a CSP header is present on JS files. The assets we are serving from /public should not have a CSP and not encounter those issues.

[zachmargolis]

LGTM!