Using custom domain with AppStream and no applications are available

0

I have a fully working custom application in AppStream 2.0. I can create a streaming URL and it works great. I followed the instructions for using a custom domain and it successfully goes to the appstream page, but it's saying "No applications available. Please contact your IT administrator for assistance." All I'm doing is replacing the "appstream2.us-east-1.aws.amazon.com" with my custom domain, keeping the authenticate?parameters clause intact. I've tried adjusting which headers are cached but it doesn't seem to change anything. Any ideas?

gefragt vor 2 Jahren1125 Aufrufe
1 Antwort
1
Akzeptierte Antwort

Can you try the custom domain streaming URL in an incognito/private browser, with developer tools open? I'm curious if any errors are being written to the console that might explain what's going on.

Not that it should matter, but is this an Elastic fleet or an Always-On/On-Demand fleet?

EXPERTE
beantwortet vor 2 Jahren
  • Good idea. I am seeing tons of errors in the console (below). Don't get these errors when going to the AWS link and the application is running. Also, this is an elastic fleet. This definitely explains why there's no apps, I'm just not sure where the 400 error is coming from, yet the AppStream 2.0 landing page appears fine.

    /ctrl/catalog/all-apps:1 Failed to load resource: the server responded with a status of 400 () prod_v9a8a867591b8ff517d78b33fce455378e66bb4ce.gz.js:5647 [2022-02-12 05:38:59:515 PST][ERROR][CatalogService] Error getting apps: [object Object]

  • I can't seem to replicate the behavior you're seeing unfortunately, no matter how much I tweak the Cloudfront distribution. Most likely will need a support request to understand why the API call to fetch the applications list is failing specifically when using a custom domain/Cloudfront. I'll ask around internally to see if anyone else has experienced this, too.

  • I have it working now, but I can't pinpoint what the exact fix was. One item that was missing was the wildcard portion of the subdomain. I set it up in the SSL certificate, but did not define a wildcard CNAME in the DNS record. That changed the behavior somewhat, but I also had to alter the caching settings. It seems like the Cloudfront options are different than the documented steps, such as forwarding cookies. So I believe a combination of those two items got it work. Really appreciate the help, got me pointed in the right direction.

Du bist nicht angemeldet. Anmelden um eine Antwort zu veröffentlichen.

Eine gute Antwort beantwortet die Frage klar, gibt konstruktives Feedback und fördert die berufliche Weiterentwicklung des Fragenstellers.

Richtlinien für die Beantwortung von Fragen