While configuring a different setting, I discovered it couldn’t save because an existing setting wasn’t accepted anymore. In allowed web orgins, the origin ‘http:/localhost:4200’ wasn’t valid anymore. It was already configured, so it was valid at some time, and even the text below says it should be accepted.
List of allowed origins for use with Cross-Origin Authentication and web message response mode, in the form of “://” “:” ], such as https://login.mydomain.com or http://localhost:3000.
Ups! On a serious tone, thanks for reporting this. That was an unfortunate side-effect of improving the validation because people were providing values including path component which would then fail the web origin check.
We’re already aware of this situation and it will be addressed as soon as possible (it depends on the deploy pipeline). For now you can either perform the update of that property through the management API or avoid localhost itself and just map another name to 127.0.0.1. Personally, localhost has enough special treatment by so many parties (including browsers) and is so exceptional that if you are developing a web application you might want to just do all the testing/development using test domains mapped to 127.0.0.1 and avoid all the specificity of localhost.
Updating it via the management API does indeed still work, thanks!
Thanks for letting us know about that also; you should check this answer to a related question that also addresses the situation relating IP addresses.