"You do not have permission to view this directory or page" Mvc 4 app on Azure

2
votes

I have 2 webapps on windows azure. Everything worked fine. Then I had to renew my ssl certificate, as I did in the Configure-section, and pressed Save.

After this I get "You do not have permission to view this directory or page." on all webapps that are on a subdomain (maybe just coincidence).

Everything worked before so it's not an actual issue with the code. I have manually deployed, redeployed, restarted the apps. Even undo my changes with the certificated and swap my deployment slot back to the staging slot. I can not get rid of 'You do not have permission to view this directory or page.'

I cannot reach any file of the app. The only thing that seems to work is the app_offline.htm file when enabled.

The only solution I can think of right now is to completely delete the azure webapps and create a new app again, which would be unacceptable, but considering this downtime affects production apps as speak, maybe worth it.

One other weird thing I noticed, I'm still using the old azure control panel, where I see my 6 webapps (2 on subdomains, 4 landing pages on 'main' domains). However, if I go to the new Azure portal, the 2 on subdomain apps don't exist... If I click the link in the old portal from my subdomain-webapp, I get 'asset not found, possibly deleted'.

Please help.

1
.netasp.net-mvcazureiisazure-web-app-service

1 Answers

2
votes

Everything is working again, why it all went wrong is still beyond me but this is the wrap up:

  • I went to old portal and uploaded a new SSL certificate for my webapps.
  • After uploading and changing the domain to use the new certificate, the webapps became unavailable for visitors, resulting in the “You do not have permission to view this directory or page” error.
  • When trying to see if the Authorization/Authentication settings were causing it I couldn't access this in the new portal because resources weren't sync.
  • After syncing resources (with help from Azure support) it turned out that the Authorization/Authentication settings were set to enabled, and 'use Active Directory' instead of allow all as they were before, even though I have never (ever) touched these settings.