I really like the swapping of deployment slots feature of Azure websites for release management. But I am unsure as to use it for my current configuration.
I have wildcard subdomains in my site and users’ authenticated sessions are persisted across the root domain and any subdomains. In order to accomplish this I have to specify the domain for my cookies in the web.config such as domain=”.mysite.com”. I have that all working properly. The next thing I did was get this to work for my different build environments (dev, staging, production). I did that by using web.config transforms. So if it’s a web.config(debug) transform then my auth cookie is specified as domain=”mysite-dev.com” or if it’s web.config(release) then it’s domain=”mysite.com”.
Here's my current Configuration:
Dev Build - web.config (debug)
<system.web>
<authentication mode="Forms">
<forms name="FormsAuth" loginUrl="http://example-dev.com/Login.aspx" defaultUrl="http://example-dev.com" domain=".example-dev.com" />
</authentication>
<httpCookies domain="example-dev.com" />
</system.web>
<system.identityModel.services>
<federationConfiguration>
<cookieHandler name="MySite" domain=".example-dev.com" requireSsl="false" />
</federationConfiguration>
</system.identityModel.services>
Production Build - web.config (release)
<system.web>
<authentication mode="Forms">
<forms name="FormsAuth" loginUrl="http://example.com/Login.aspx" defaultUrl="http://example.com" domain=".example.com" />
</authentication>
<httpCookies domain="example.com" />
</system.web>
<system.identityModel.services>
<federationConfiguration>
<cookieHandler name="MySite" domain=".example.com" requireSsl="false" />
</federationConfiguration>
</system.identityModel.services>
Question 1:
How do I test wildcard subdomains in a Azure staging environment and maintain authenticated sessions? Because authentication cookies will not work properly in the staging environment when it has the production configuration of cookie domain="example.com" when it should be set to domain="example-staging.com". The only thing I can think of is to create web.config (staging) build but that would break production as soon as I swap the staging slot to production.
Question 2:
Can you bind your own custom domain to the default Azure staging URL? So instead of using example-staging.azurewebsites.net I could use example-staging.com. I ask this because it doesn’t look like Azure supports more than one level of subdomains on their default app url. For instance you cannot do subdomain.example.azurewebsites.net. So the only way I can think of to accomplish this is bind my own custom domain to the staging deployment slot so that I can do subdomain.example-staging.com.
Has anyone dealt with a similar scenario?