Static-web-apps: Feature Request - Custom Domain for Staging Site

[HiltonGiesenow]

I've tried creating a cname, but it didn't work, not sure if I just messed something up, or if it's not supported. Aside from that, I think the title is quite self evident :-)

[miwebst]

This is not supported right now :)

[HiltonGiesenow]

That's why I've titled it "Feature Request" ...

[miwebst]

Understood. I was confirming your earlier comment: "not sure if I just messed something up, or if it's not supported"

[HiltonGiesenow]

ahh ok, my mistake - thanks for confirming. I was wondering if any of this would be open sourced at any point, in which case I'd be happy to work on a PR. Not the Azure portion itself necessarily, just the Github Action component I mean

[m-sterspace]

@HiltonGiesenow my workaround for this was just to create more Static Web App instances with the same github repo. We typically have 3 different hosting environments per app, production, staging, and develop, so I created 2 more Static Web Apps, but each one associated with a different branch of the same repo, so there's now have 3 different workflow files, one each for the master, develop, and staging branches:

[HiltonGiesenow]

that's a great idea, thanks. It might change when this goes g.a. and has pricing attached, but it'll certainly work for now

[m-sterspace]

In a related, but slightly different request, I would really like the ability to have dedicated/stable URLs for deployment slots. Being able to set them up with a custom domain and a cname record as well would be ideal, but I care less about that then just having a stable URL for a staging slot.

If you implement your own authentication for your application, either using the MSAL library or Auth0s or just rolling your own OAuth setup, you need to have a stable callback url for each of your sites that is registered with the authentication providers. At present you can't really easily set that up since staging slots always get a brand new random url.

[mwaddell]

This is really more of a DNS issue. In order to map your production slot to another url, you need to use a CNAME. There isn't any "dynamic" equivalent to a CNAME that would let you do pattern matching (e.g. map fuzzy-stone-*.azurestaticapps.net to staging-*.mycompany.net).

Besides, the whole benefit of SWA is that you get a separate phoenix environment for every PR. If you want to have a fixed location for your staging environment, then just use a separate branch. For example, instead of trying to do everything in your "main" branch, have a separate "prod" branch and using "main" as staging. Then you get a static URL for the staging branch, phoenix environments for every PR against staging, and a separate static URL for production -- that also gives you an additional audit step between staging and production which can have different sign off users in the branch protection rules.

If you want to have 3 separate statically named environments, then don't use PRs at all - just set up 3 branches and push everything to the one you want it to deploy to. This is how we manage things that don't support phoenix environments (like some legacy dotnet framework apps)

[m-sterspace]

This is really more of a DNS issue. In order to map your production slot to another url, you need to use a CNAME. There isn't any "dynamic" equivalent to a CNAME that would let you do pattern matching (e.g. map fuzzy-stone-*.azurestaticapps.net to staging-*.mycompany.net).

Besides, the whole benefit of SWA is that you get a separate phoenix environment for every PR. If you want to have a fixed location for your staging environment, then just use a separate branch. For example, instead of trying to do everything in your "main" branch, have a separate "prod" branch and using "main" as staging. Then you get a static URL for the staging branch, phoenix environments for every PR against staging, and a separate static URL for production -- that also gives you an additional audit step between staging and production which can have different sign off users in the branch protection rules.

If you want to have 3 separate statically named environments, then don't use PRs at all - just set up 3 branches and push everything to the one you want it to deploy to. This is how we manage things that don't support phoenix environments (like some legacy dotnet framework apps)

This is why I had asked for the option for static deployment slots as opposed to dynamic ones. Once this service exits preview I'd rather not have to pay for three instances of it just to have dev and staging deployment slots that will barely be used.

Dynamic deployment slots and URLs only work if your app either doesn't have authentication, or if you use the built in authentication. If your app is trying to be relatively platform neutral so that it could be easily deployed anywhere, and you're handling authentication yourself using something like the msal.js library, then a dynamic url is a non starter as every callback url has to be registered with your oAuth provider.

[mwaddell]

@miwebst - do you have any idea what the pricing will look like for SWA once it hits GA? Will there be a significant cost difference between having 4 different SWA instances where no staging slots are used vs having a single SWA instance with 3 staging slots?

Will the staging slots have to use the same pricing model as the production slot? If so, having 4 different instances might actually be cheaper if I can use consumption-based pricing on my 3 staging instances and only use a dedicated pool on my production one.

[mwaddell]

We've been using Auth0 with SWA and it supports wildcard callback URLs, so it hasn't been a problem for us. I don't know about other oAuth providers.

[m-sterspace]

We've been using Auth0 with SWA and it supports wildcard callback URLs, so it hasn't been a problem for us. I don't know about other oAuth providers.

It shouldn't support wildcard callback URLs, as that goes against the OAuth standards, all the callback URLs should be absolute:

https://docs.microsoft.com/en-us/azure/active-directory/develop/reply-url#restrictions-on-wildcards-in-redirect-uris
https://tools.ietf.org/html/rfc6749#section-3.1.2

[mwaddell]

We've been using Auth0 with SWA and it supports wildcard callback URLs, so it hasn't been a problem for us. I don't know about other oAuth providers.

It shouldn't support wildcard callback URLs, as that goes against the OAuth standards, all the callback URLs should be absolute:

https://docs.microsoft.com/en-us/azure/active-directory/develop/reply-url#restrictions-on-wildcards-in-redirect-uris
https://tools.ietf.org/html/rfc6749#section-3.1.2

True, and it is noted in auth0's documentation that this is only intended for dev/test environments, and should not be used on production. They also do put some restrictions on wildcards (e.g. no *.com, etc) but I do understand that this is non-standard and not likely to be supported on oAuth providers generally.

• https://auth0.com/docs/applications/wildcards-for-subdomains

I agree that the most flexible solution would be to modify the "Custom Domains" section of the SWA portal to list 1 production slot and N staging slots (depending on how many you've purchased - 1 for now). They could default to "random-words-hashcode-#.eastus.azurestaticapps.net" (where "#" gets replaced by the PR number) - but let users override those to something static.

However, this is basically the same as maintaining a separate branch for each staging "slot" and merging the PR branch you want to test into the "slot" branch you want to deploy it to for testing. This is possible to do with automatically with GHA instead of manually if you're creative (e.g. have a workflow that automatically merges that branch's changes into a specific slot's branch based on the label associated with the PR) but it's definitely less slick than having Azure manage that for you, and it's also unclear whether there will be any cost difference to having 2 production slots with no staging slots vs 1 of each.