The example here to provide a function to allow dynamic origins doesn't behave the same way as when you pass strings, arrays of strings, arrays of regexps etc as the allowed origin.

If you pass an origin function that calls back with an error, the error propagates onwards preventing the route handler that would otherwise be called from being called, and you get an unsuccessful HTTP response.

This has other undesirable side effects like preventing non-browser access to a server (#142 updated the docs to suggest a workaround for this), and preventing same-origin access to a server using the CORS middleware (which there is no workaround for, unless you count including the domains intending to do same-origin requests in the allowed cross-origin list)

If you provide a string domain as the allowed origin, though, and you try to do a cross-origin request from a disallowed origin, the request goes ahead as normal. The access-control-allow-origin header is not included in the response as expected (which prevents the response leaking to scripts on the disallowed origin), but there is no impact on same-origin requests or non-browser access when the module is configured this way.

Which behaviour is the expected one? What I'm getting from the spec is that it's probably the second one, that CORS alone should not be relied on to prevent request side-effects, and a CSRF token should be passed in these cases.

This pull request updates the documentation to suggest calling back with (null, false) instead of an error, to bring the behaviours between the different configurations more in line, and remove the need for cases like non-browser access to need special workarounds.