Private Supermarket redirects to hostname not FQDN

I am having a problem similar to https://discourse.chef.io/t/supermarket-in-azure/9777.

I installed Supermarket 3.3.3 on a from CentOS 7.6 instance running in Azure. When I go to the web site using the FQDN, I am redirected to the hostname which cannot be found. https://ggsupermarket.eastus.cloudapp.azure.com/ redirects to https://ggsupermarket/. I can't find anywhere that the FQDN isn't set to the full FQDN.

[ggotimer@ggsupermarket ~]$ hostname
ggsupermarket.eastus.cloudapp.azure.com
[ggotimer@ggsupermarket ~]$ hostname -f
ggsupermarket.eastus.cloudapp.azure.com
[ggotimer@ggsupermarket ~]$ hostname -s
ggsupermarket

[ggotimer@ggsupermarket ~]$ sudo supermarket-ctl show-config | grep fqdn
  "fqdn": "ggsupermarket.eastus.cloudapp.azure.com",

[ggotimer@ggchef2 ~]$ sudo cat /etc/opscode/oc-id-applications/supermarket.json | grep redirect_uri
  "redirect_uri": "https://ggsupermarket.eastus.cloudapp.azure.com/auth/chef_oauth2/callback",

From Chef Automate:

Anyone have any ideas? Does anyone know where the redirect URL comes from if it isn't using the FQDN or the configured redirect_uri? Or why it might not use the redirect_uri?

Hi, Gene!

One of the first redirects that can occur in a supermarket instance is by NGINX. What appears as server_name in the rendered config at /var/opt/supermarket/nginx/etc/sites-enabled/rails?

It looks right there.

[ggotimer@ggsupermarket ~]$ sudo cat /var/opt/supermarket/nginx/etc/sites-enabled/rails | grep server_name
  server_name ggsupermarket.eastus.cloudapp.azure.com;
      return 301 https://$server_name$request_uri;
  server_name ggsupermarket.eastus.cloudapp.azure.com;

But it looks like it is working now, at least in some browsers. It works in Edge but is failing in Firefox, still redirecting to https://ggsupermarket/ rather than https://ggsupermarket.eastus.cloudapp.azure.com/.

Maybe it is just a browser problem handling the self-signed cert?

I confirmed it is working in Chrome and Edge, but redirecting to the wrong/shortened URL in Firefox. I can't see a cause but it also doesn't look like a Supermarket issue in any way.

Thanks for your help.

Was there ever a time that this supermarket instance was reachable as https://ggsupermarket/ and you may have visited it in that Firefox? If so, that 301 (permanent) redirect in the NGINX config that you quoted could have taught your Firefox that any request to go there really goes to ggsupermarket.

We need to burn that 301 with fire. (Or, really, replace it with a 302.)

I don't think so, but that doesn't mean it wasn't. But that would make sense based on what I am seeing.

So hard to tell a browser to forget permanent redirects. That's why the recommendation these days seems to be not to use them, just use 302s. Which is why I should get on replacing the 301s in Supermarket with 302s.