Allow CORS and CORP Headers, Enabling SharedArrayBuffer

[a904guy]

I've updated the livereload to allow for setting Cross-Origin-Embedder-Policy to "cross-origin", so it will work with other sites that require-corp, and same-site headers. Allowing you to use SharedArrayBuffer in modern browser versions.

Example using SIRV with this pull, livereload then needs modification to work correctly.

Explaining the need: Blog Regarding SharedArrayBuffer

Necessity/Purpose: So that you can work locally with @ffmpeg/ffmpeg which relies on SharedArrayBuffer

[a904guy]

Without modification, livereload is being blocked:

After modification and proper headers:

Functionality returns and WS is connecting, reloads properly.

[napcs]

@a904guy This is a nice implementation. There's a PR I've been sitting on (#155) for CORS but there were some questions about that. Going to take a deeper look at this though because I'm trying to build out the tests more to cover these options. Any chance you could help out by adding test cases for these options?

[a904guy]

I can, give me a bit.

I'll take a look when I'm off.

Just a note, this should be considered different than standard CORS, it's the Cross Origin Resource Policy. Which was introduced to handle SPECTRE CPU vulnerabilities. You can see where I accidentally wrote CORS header before modifying it here in another commit

CORS is a bit tougher because there are a bunch variations on ways to configure them, based on source/origins, ect.

EDIT (After thinking about it): For LiveReload, I think you only really need one CORS setup though. Allow all. It's not like this is for a production environment.

[a904guy]

I added the tests for CORP as requested.

  livereload config
    ✓ should remove default exts when provided new exts
    ✓ should incldue default exts when provided extraExts
    ✓ extraExts must override exts if both are given
    ✓ should support filesToReload
    ✓ should support CORP headers

  livereload headers
    ✓ should set the correct CORP headers (61ms)

Let me know if I can assist with the CORS side. Looks like a different approach than mine was taken with the "defaultHeaders" variable, not much different, could be adapted easily.

[a904guy]

@napcs I looked over both CORS requested PR/Issues. I've implemented what they wanted and the related tests.

You can define { cors: true } or { cors: 'domain.name' } and the headers will respond.

Additionally from command line, it would be --cors or --cors 'domain.name'

  livereload config
    ✓ should remove default exts when provided new exts
    ✓ should incldue default exts when provided extraExts
    ✓ extraExts must override exts if both are given
    ✓ should support filesToReload
    ✓ should support CORP headers
    ✓ should support default CORS headers
    ✓ should support a specific CORS headers

  livereload headers
    ✓ should receive the correct CORP headers (66ms)
    ✓ should receive the correct default CORS headers
    ✓ should receive the correct sepecfic CORS headers

[a904guy]

@napcs Setting both CORS and CORP settings, I've verified they both working appropriately.

[a904guy]

@napcs This is the final change. It's a speed optimization.

By moving the if conditions to the higher level function, they'll only need to evaluated once, at time of createServer being called. Moving them out of requestHandler means they don't need to be evaluated on every single request to the JS file.

EDIT: Regarding the allowed methods, "OPTIONS, HEAD, GET, POST", I concur that post isn't needed for current functionality, but perhaps in the future it may? You can adjust as wanted.

[napcs]

@a904guy holy smokes this is incredible. I'll look later this week. Thanks so much for the work here.

[ArtskydJ]

Just curious if there's anything blocking this PR? I'm interested in using node-livereload with CORS, and might be able to help if needed.