Ok so for multiple reasons, I changed the network settings of an app service so that it cannot be accessed using its .azurewebsites.net url
It works but it displays the default "Forbidden" page. What I would like to do is have it display something like this:
If I can extend it to returning a failed status instead of a 403, that would also be awesome.
Creating custom error pages in cases of 4XX and 5XX errors is not supported out of the box with Azure App Services as of today, but it is a heavily upvoted and requested feature on their UserVoice forum. Please upvote it so the Product Group can prioritize it accordingly.
To work around it, you could use an Application Gateway to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.
Custom error pages are supported for maintenance and unauthorized access scenarios, and can be defined both at global and listener levels.
The configuration through Azure Portal and Azure PowerShell is explained in detail in this article: Create Application Gateway custom error pages
Related
In the Azure Portal, in certain scenarios when it prompts me to open a URL in a new tab, I get a 403 error.
"Error 403 - This web app is stopped"
I have followed the help link on that page (https://blogs.msdn.microsoft.com/waws/2016/01/05/azure-web-apps-error-403-this-web-app-is-stopped/), but none of these issues (see footnote for issues) apply to me.
Specific examples of when I get this message:
In an app service > App Service Diagnostics > Collect Memory Dump: the report is available to view in a pop-out URL. When I click on the link, it opens a new browser tab and I can see from the url that it's attempting an oauth sign-in, which eventually displays the 403 page.
In an app service > App Service Editor (Preview), when I click on the "Go" link, as before, it opens a new browser tab and I can see from the url that it's attempting an oauth sign-in, which eventually displays the 403 page.
In both cases, it redirects to a https://****.sso.azurewebsites.net url which displays the 403 message.
Any suggestions?
Footnote: According to that url, there are 3 conditions that can cause this error to be presented.
The site has reached a billing limit and your site has been disabled.
The Website has been stopped in the portal.
The Azure Website has reached a resource quota limit that applies to either Free or Shared scale modes.
Based on Ivan's comment, I checked my role settings. I was a Contributor for this Azure subscription. Since I changed it to an Owner (via Access control IAM > Role Assignments), it now works as expected.
It's frustrating that this is not made obvious in the Azure Portal.
In my case, There were network IP restrictions applied to the site. So I was getting the same error above from my home network. You can check the rules by going to the properties tab. To modify, go to Networking->Configure access restrictions.
If you are only getting the error when you open a new tab, it could be a problem with the maximum number of connections.
Are you running in debug mode? For Basic and below the maximum number of debug connections is 1.
I have a web app in Azure. The access to that web app is controlled by Azure Active Directory. The app is up and running since September of last year. I didn't make any changes to the app for a while and have 33 users in that app.
So, a week ago I tried to add a user, using the same methods and paths I used before.
The new user can log in to microsoft (portal.office.com). After the initial log in and changing of the password the user goes to the web app in Azure and get the following error: You do not have permission to view this directory or page.
Error tracing gives me this:
HTTP Error 401.73 - Unauthorized You do not have permission to view
this directory or page.
Most likely causes: The authenticated user does not have access to a
resource needed to process the request.
Things you can try: Create a tracing rule to track failed requests for
this HTTP status code. For more information about creating a tracing
rule for failed requests, click here.
Detailed Error Information: Module EasyAuthModule_32bit
Notification BeginRequest Handler
ExtensionlessUrlHandler-Integrated-4.0 Error Code 0x80004005
Requested URL https://*******:80/.auth/login/aad/callback Physical
Path D:\home\site\wwwroot.auth\login\aad\callback Logon Method
Not yet determined Logon User Not yet determined
More Information: This is the generic Access Denied error returned by
IIS. Typically, there is a substatus code associated with this error
that describes why the server denied the request. Check the IIS Log
file to determine whether a substatus code is associated with this
failure. View more information ยป
Microsoft Knowledge Base Articles:
Another observed behavior: usually when new users are logging in the web app asks for permissions for the AD to access their account information. Ever since this problem came up this is not the case any more.
Other users do not have any problems logging in. This problem only happens with new users who never logged in before.
EDIT: When I go to Active Directory and look at sign ins, I see failures to log into the web app with sign-in error code 90092. Failure Reason: Other.
Microsoft help desk could not give me details on that error code.
Checkout the related question and answer here. All new users have to first consent the application (agree and give your application permissions to access their profile / or you indicated as required permissions).
In short, you have to design "sign-up" button for your application, which uses the "login_url" and appends "&prompt=consent" to the query string.
Read all related resources here to better understand the consent framework.
And please read the documentation about Azure App Service Authentication/Authorization here, as well as the Azure AD specific documentation here.
OMG, I just found an answer. I created a test app and set it up to mirror the settings of my live app.
In Required Permissions the new app had nothing for Microsoft Graph, the live app had 5 permissions. I deleted Microsoft Graph and it works now!
I wish Microsoft communicated better about discontinued API's. I did get an alert, but it was mostly talking about MS Office 365.
I am trying out the Azure AD-B2C. The user signup/sign in is fine when the MFA is turned off. But when I turn it on, and the user tries to sign in and provides the phone number, and requests a text message by clicking "send code", I get the Http 400 error: size of request headers is too long. Anybody else have this issue?
The error HTTP 400: Size of header request is too long generally happens because there's too many cookies.
Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem.
Clearing the cookies should resolve this problem. If this is happening on a recurring basis, you should edit your question to include details about the request and cookies in order to best figure out what's bloating the request and how to reduce it.
Short answer: The file with the custom UI was not found by Microsoft login service. After getting shipped around it resulted in the error.
I had the same error with AAD B2C but "cookies" was not the problem. In my case I got the error while testing in the Azure B2C portal checking the policies and the custom UI pages. We use Azure Blob storage to hold custom login setup, its fast and it scales without our attention. The problem was found by using my test website using the B2C service. I put a stop/break on the Account controller's "public Task OnRemoteFailure(RemoteFailureContext context)" method. The debugger message gave me the full context of the error, an http 404 error and it gave the file name it was trying to find. Blob storage is case sensitive. The setup configuration used to configure B2C has camelCase names. The group who created the actual UI customization uses all lower case names. It took someone with access to all the assets to find the simple case name issue. Errors in distributed systems can be difficult.
I would like to log the "Event URL" field in Kentico Portal logs to Azure Application Insights for 404 requests. Since I changed my custom page for 404 errors in Kentico Portal I only get "PortalTemplate.apsx" for the url field in the requests table in AppInsights.
We already have this as a recommendation on the GitHub - use RawUrl instead of Request.Url.
As explained here RawUrl better suites cases when the request was redirected to the custom error page: Request.RawUrl vs. Request.Url
Please upvote the issue on GitHub. As a workaround now you can replace OperationNameTelemetryInitializer in ApplicaitonInsights.config to your own implementation of it that uses RawUrl instead of the Url.
I am working on Azure App service API apps.
I followed the steps available in the below link, for implementing user authentication concept to the ToDoListAngular project and successfully deployed in azure, but when i test with the ToDoListAngluar project azure url to add the todoitem it shows error on Google Chrome Address bar "This page is trying to load scripts from unauthenticated sources".
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-user-principal-auth/#overview
Please tell me how to resolve the above error.
It sounds like one of your API Urls does not have https:// at the beginning.
My best bet is the "toDoListAPIURL" in your front end site's application settings on the portal. There are a ton of API urls in the source code to check if that doesn't do it. Going back through the getting started tutorial should have them all.