Origin parameter should be parsed with query string library

[ktamaral]

The origin parameter is being appended to the end of the login url with direct string manipulation, e.g. ${url}?origin=${window.origin}

This is problematic in some use cases where pre-existing parameters may need to be passed through to the login service. In the case where pre-existing parameters exist in the origin url, this results in a url with two “?” delimiters, one for the pre-existing parameters and another for the origin at the end. Therefore, any pre-existing existing parameters will not be readable by the login service. In our use case at Harvard Library, we do have some pre-existing parameters that are required for the login process. We're currently working around the issue by processing the url to remove the redundant "?" delimiter before it is parsed by the login service.

Ideally, this would be done in Mirador by appending the origin parameter using a string parsing library (such as the builtin UrlSearchParams library). This will allow any pre-existing parameters to be properly parsed and added in to the url when it's reconstructed by the Mirador code.