[braddf]

Pull Request

Description

Two small ones that missed #391.

Model names in detail=full metadata. Zak spotted that the metadata we now parse into an object shows the DP's forecaster names instead of the public API "pretty" ones, so app_version came back keyed by things like pvnet_day_ahead that a user won't recognise and can't use in the API. They're now translated to the latest API names (ecmwf_mo and friends), keys and string values alike, on exact matches only so anything not in that list passes straight through. The mapping is built from country_config, so a new model is covered without a second list to keep in step.

N.B. – a DP name sometimes does work as input: pvnet_day_ahead and pvnet_ecmwf are accepted, but only because they're retired public slugs we kept as aliases that happen to match the DP names. pvnet_v2 was never public so it 400s, and the NL ones all 400. And since aliases pin the adjuster off, a user copying pvnet_day_ahead out of the metadata and passing it back gets the unadjusted forecast where ecmwf_mo gives them the adjusted one – same model, quietly different numbers. This is down to user behaviour though, and there are loads of ways one can confuse themself with/without the adjuster and other params set, so I think this is fine.

One extra note: a model and its _adjust variant share one API name, so if both ever happen to be in the same object one would overwrite the other. In that case they keep the DP names rather than lose a version number, but I can't see when this would ever happen as it is atm.

OAuth redirect URL on deployed environments. #391 started sending the redirect explicitly so Scalar couldn't lose it, but took the scheme from request.url, which is http behind the load balancer since TLS is terminated upstream. No proxy locally so it looked fine, but on dev it wasn't which was odd.. turns out the docs page was returning Auth0 an http:// callback. Now uses X-Forwarded-Proto where it's set.

The general version is still open, if we want it: gunicorn's UvicornWorker only trusts that header from forwarded_allow_ips, which defaults to loopback, so anything else building a URL from request.url has the same problem. Setting FORWARDED_ALLOW_IPS on the container fixes it everywhere, but that's a deployment change rather than a code one so #393 has it and we can revisit later.

Checklist:

• My code follows OCF's coding style guidelines
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I have checked my code and corrected any misspellings