password-manager-resources
password-manager-resources copied to clipboard
consider adding example URLs for automated testing of shared backends
I propose adding URLs for the shared backend groups. As shown below.
The URL should point to a page on that domain, that returns a 2XX-3XX HTTP response (e.g., redirects ok), and (preferably) includes at least one HTML form element for a username.
The goal here is to enable minimal automated testing of these groups, and also to indicate when a group is no longer necessary.
[
{"kcls.bibliocommons.com", "https://kcls.bibliocommons.com/user/login"},
{"kcls.overdrive.com", "https://kcls.overdrive.com/account/ozone/sign-in"},
{"kcls.org", "https://login.ezproxy.kcls.org/login"}
],
I have made some attempts to test some of the URLs already in the repo for validity, but the Internet is large and held together with baling wire - there were password reset pages that have 401 redirects and ea.com causes cURL to go into a redirect loop.
@rmondello seems less than thrilled to add network-based validation: https://github.com/apple/password-manager-resources/pull/130#issuecomment-640251583
I'm beginning to lean that way too.
do you think there is value in having the URLs there as an option to be used downstream by password managers?
also -- it would make manually verifying new pull requests easier, a matter of clicking the link compared to hunting around for the "login" page on each domain.
I see that point that headless/network-based validation is a challenge, especially for these quirky URLs
I don’t like validating the URLs, but I like documenting them!
(Although, citing them in the pull request documents them in a weak way.)
To the points above, I don't think adding specific login/signup URLs for backends helps password managers themselves but only tooling or humans to validate them more easily. I would be in favor of not adding them to the repo for this reason. It makes more sense to validate things using the core information in the resources if at all possible