1 Answer
- Newest
- Most votes
- Most comments
1
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?
Relevant content
- Accepted Answerasked 2 years ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
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.