The default naming for AppService resources generates a URL which triggers Chrome "deceptive" browser heuristics

[ctolkien]

All the templates use a naming convention which includes a resourceToken of var resourceToken = toLower(uniqueString(subscription().id, name, location))

Using this style URL is tripping up Chromes deceptive site heuristics:

[ellismg]

Not 100% sure what we'll be able to do here. We use the random suffix (based on the subscription ID and environment name) so we don't have to ask the user to pick unique values.

We could consider allowing configuring the hostnames of these services (via parameters) and just default to the random suffix but that would be something folks could opt into.

I just tried this using Chrome 108.0.5359.125 (Official Build) (64-bit) (cohort: Stable Installs & Version Pins) and wasn't able to reproduce this issue to a version I deployed to test this at this endpoint: https://app-web-s5de7fsxm2g4u.azurewebsites.net/ which seems like it should have triggered any heuristics. Since I don't normally use Chrome (I use Edge) I'm not sure if this is due to it being a fresh install or not. I haven't seen this behavior in Edge.

Reading about this a little (it was difficult to find authoritative information), I got the impression that one of the heuristics may be tied to other similar URLs in your local history. Just wondering, @ctolkien - had you been deploying multiple copies of these templates and have similar URLs in your local history?

[jongio]

I haven't seen this issue on Edge

@ctolkien - What Chrome version are you using? Can you try in private mode?

Thanks

[rajeshkamal5050]

Closing this issue for now, but if you run into this or able to repro. Please feel free to re-open.

[savannahostrowski]

I also experienced this last week in Chrome (Version 111.0.5563.147 (Official Build) (64-bit)). Re-opening.

[rajeshkamal5050]

Can we add it to FAQ? @ellismg

[ellismg]

Because the resource names need to be globally unique, and our todo templates are designed to be deployed with minimal configuration by anyone, we use this random suffix trick to generate a name with a low likely hood of collisions. Even if two customers pick the same azd environment name, since they will be in different subscriptions, they'll get different unique suffixes (with high probability) and the names will not collide.

Our Todo templates allow configuring the name of the resource, if you'd like:

https://github.com/Azure-Samples/todo-nodejs-mongo/blob/0898f74496cddd9761800a2c1c53fd5bb8e70be2/infra/main.bicep#L25

To configure this parameter, you can add another entry to the main.parameters.json in the infra folder:

For example, if you include the following in main.parameters.json:

"webServiceName": {
    "value": "my-unique-name"
}

This will cause the template to create a resource named "my-unique-name" instead of something like "app-web-aj84u2adj".

You'll need to ensure the name you pick is unique, otherwise you'll get an error during azd provision from ARM when it tries to create the resource.

Note that if you've already created an App Service, changing the name her will cause a /new/ version to be created. So you'll need to either manually remove the old one via the Azure Portal, or use azd down to remove all the previously deployed infrastructure and then azd provision to create it again, this time using the new name for the web service.

[ellismg]

@gkulin - Let me know if you need any more information to craft a suitable FAQ entry for this, hopefully this provides enough background as to why we did this and what you can do if you hit it.

[gkulin]

closed with above PR. We added this to the FAQ. https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/faq#my-app-hosted-with-azure-app-service-is-triggering-a--deceptive-site-ahead--warning--how-can-i-fix-it