2

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?

Brendan Green
  • 11,676
  • 5
  • 44
  • 76
Jason
  • 21
  • 1

0 Answers0