Trying to create token with scope https://cnt-prod.loadtesting.azure.com
Hello. I have created a web app, and updated its permissions within Azure App registration. To be able to access Graph, and Azure Management (user impersonation) Using Microsoft.identity.Web I am able to add a downstreamAPI, and make a successful call to it. response = await downstreamApi.GetForUserAsync<HttpResponseMessage>("Azure Management", options => { options.RelativePath = relativePath; }); if (response?.IsSuccessStatusCode ?? false) { string responseData = await response.Content.ReadAsStringAsync(); } However when I try to create a token with a different scope, for example. var token = await tokenAcquisition.GetAccessTokenForUserAsync(new[] { "https://cnt-prod.loadtesting.azure.com/.default" }); The general error I get is that my app is trying to access a resource its not allowed to. However I cant find this resource at all to give it access (Within App Registration and API permissions) With Azure Load Testing, I have learned there is a resource plane and a data plane. The resource plane requires management.azure.com, but the access to the data plane requires https://cnt-prod.loadtesting.azure.com/.default (from the tests I have done in powershell). Anyone else come across this similar issue? Any assistance is greatly appreciated. Thank you
Azure App Service Flask Deployment issues with Error "didn't respond to HTTP pings on port: 8000"
Hello Everyone, I am Deploying the Flask Web app with Immersive Reader and I am trying deploying it by a ZIP file, tried with visual studio code too by the steps mentioned over the link below: https://learn.microsoft.com/en-us/azure/app-service/quickstart-python?tabs=flask%2Cwindows%2Cazure-cli%2Czip-deploy%2Cdeploy-instructions-azportal%2Cterminal-bash%2Cdeploy-instructions-zip-azcli So, I have gone through each step mentioned there and applied it and showing me the below result. I have gone through diagnostic resources. But didn't find any solution for the following error in logs.
AD B2C - Custom Policies - RaiseErrorIfClaimsPrincipalDoesNotExist in Password Reset journey
Hi, I'm using custom policies in our web app. For the Reset Password, I'm using the standard PasswordReset user journey provided with the local account starter pack. This journey references to <UserJourney Id="PasswordReset"> in the TrustFrameworkBase policy. At the moment, if a user is not registered in the web app, the password reset journey still sends an OTP to the email. The email receives the OTP, even if not registered, and can insert the code. Once the code is validated, clicking on the "Continue" button does nothing. The user is stuck on the page without any information. Checking the console I found out that the SelfAsserted call returns the error "404 user not found". I would like to stop the user before sending the OTP and inform him with an error message (that the account is not registered and to proceed with the registration). I tried to add: <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item> in the TechnicalProfile of the first OrchestrationStep, but it does nothing. Any suggestion on how to stop a non existing user from proceeding to the Reset Password journey? Thank you very very much if you can help me.Introducing Microsoft Playwright Testing private preview
Explore Microsoft Playwright Testing, a new service built for running Playwright tests easily at scale. Playwright is a fast-growing, open-source framework that enables reliable end-to-end testing and automation for modern web apps. Microsoft Playwright Testing uses the cloud to enable you to run Playwright tests with much higher parallelization across different operating system-browser combinations simultaneously. This means getting tests done faster, which can help speed up delivery of features without sacrificing quality. The service is currently in private preview and needs your feedback to help shape this service! To get started, join the waitlist. And check out the full blog post for more information. How do you think Microsoft Playwright can help you with in your app development?Azure Function App Http Javascript render simple html file to replicate jsrsasign sign certificate
Good day, Please Help. 1. In PowerBI im trying to render the javascript sign certificate of jsrsasign, i only got it working via an html file. So im trying to read the html file, simple hello to start of with. Am i better going directly to do the jsrsasign? 2. Locally on VS i got the simple function to return Hello Azure, but trying to read the simple html file executes no error but if i copy in postman i just get a 401 no content found, im not sure how further to debug as in VS i get Ok status, Nothing in Console? Anybody have an example or links plz? const { app } = require('@azure/functions'); const fs = require('fs'); const path = require('path'); app.http('IC5', { methods: ['GET', 'POST'], authLevel: 'anonymous', handler: async (request, context) => { context.log(`Http function processed request for url "${request.url}"`); // const name = request.query.get('name') || await request.text() || 'world'; // return { body: `Hello, ${name}!` }; //var res = { //body: "", //headers: { //"Content-Type": "text/html" //} //}; // readFile = require('../SharedCode/readFile.js'); //filepath = __dirname + '/test3.html'; //fs = require('fs'); //await fs.readFile(filepath,function(error,content){ fs.readFile(path.resolve('./test3.html'), 'UTF-8', (err, htmlContent) => { context.res = { status: 200, headers: { 'Content-Type': 'text/html' }, body: htmlContent } }) // if (request.query.name || (request.body && request.body.name)) { // res.body = "<h1>Hello " + (request.query.name || request.body.name) + "</h1>"; //} else { //fs.readFile(path.resolve(__dirname,'test3.html'), 'UTF-8', (err, htmlContent) => { //res.body= htmlContent; //context.res = res; //}); // } } }); //TEST IN POSTMAN: http://localhost:7071/api/IC5?name=hurry
We have just re-deployed our app to ASEv3 and its failing
I am getting several issues once I migrated our asp.net framework 4.8 app from ASEv2 to ASEv3. It should be noted that the code is identical; but we did deploy the code this time using terraform so deployment of the apps (we have multiple apps for different customers using isolated databases and subdomain name) is identical and the creation of storage accounts and all other services are the same. I have checked the configuration, env variables of the web app, and config of storage accounts (v2) are both identical between the old service and the new one. Response Streaming Firstly, we cant stream files of particular sizes to the client anymore. We just get a weird URL Rewrite error (we dont have any url rewrite rules in our web.config). Small files work fine, larger files (2mb) do not (they are txt files) from a file share on Azure Storage. Initially we couldn't stream small files either, but I disabled dynamic compression to web.config and it fixed it; but then we started getting the above issue with larger files: <urlCompression doStaticCompression="true" doDynamicCompression="false" /> What we get is an "URL Rewrite Module Error": Module: RewriteModule Notification: ReleaseRequestState Handler: System.Web.Http.WebHost.HttpControllerHandler Error Code: 0x80004004 Request Issues We have an integration test that 'PUT's an empty model to an authenticated endpoint which has no authentication (Basic Auth); previously this returned a 401 Unauthorised; now it returns a 411 LengthRequired error. This must be something to do with the validation order of the request which has changed; perhaps ASEv3 has a slightly newer/different IIS version? Remote Debugging I cannot connect Visual Studio to my web app to remote debug; I presume they have killed off ASP.Net Framework apps and only support .net core now? When I select my web app (with remote debugging enabled) from Visual Studio Attach to Process, it just presents an "Operation not suppored 0x80aa0001" error The response issue is the most important as I just cannot work out what is going wrong and what has changed. This all works locally fine, even connecting to the same (live/prod) database and storage account works fine; so its just an issue within ASEv3 which was never an issue with ASEv2.
Error loading add-in ... while manifest is ok
I developped an Excel web addin with an aspnet core 6.0 API and published it on a dedicated server on Azure. Excel raise an "Error loading add-in" error when the complement is installed on Excel. Please note that : - the xml manifest has been validated (common error in this case) - cors is enabled - the api has been tested online with swagger Does any one have a suggestion ? ThanksBest Practices for API Error Handling: A Comprehensive Guide
APIs (Application Programming Interfaces) play a critical role in modern software development, allowing different systems to communicate and interact with each other. However, working with APIs comes with its challenges, one of the most crucial being error handling. When an API encounters an issue, it's essential to handle errors gracefully to maintain system reliability and ensure a good user experience. In this article, we'll discuss best practices for API error handling that can help developers manage errors effectively. Why is API Error Handling Important? API error handling is crucial for several reasons: Maintaining System Reliability: Errors are inevitable in any system. Proper error handling ensures that when errors occur, they are handled in a way that prevents them from cascading and causing further issues. Enhancing User Experience: Clear, informative error messages can help users understand what went wrong and how to resolve the issue, improving overall user satisfaction. Security: Proper error handling helps prevent sensitive information from being exposed in error messages, reducing the risk of security breaches. Debugging and Monitoring: Effective error handling makes it easier to identify and debug issues, leading to quicker resolutions and improved system performance. Best Practices for API Error Handling 1. Use Standard HTTP Status Codes HTTP status codes provide a standard way to communicate the outcome of an API request. Use status codes such as 200 (OK), 400 (Bad Request), 404 (Not Found), and 500 (Internal Server Error) to indicate the result of the request. Choosing the right status code helps clients understand the nature of the error without parsing the response body. 2. Provide Descriptive Error Messages Along with HTTP status codes, include descriptive error messages in your API responses. Error messages should be clear, concise, and provide actionable information to help users understand the problem and how to fix it. Avoid technical jargon and use language that is understandable to your target audience. 3. Use Consistent Error Response Formats Maintain a consistent format for your error responses across all endpoints. This makes it easier for clients to parse and handle errors consistently. A typical error response may include fields like status, error, message, code, and details, providing a structured way to convey error information. 4. Avoid Exposing Sensitive Information Ensure that error messages do not expose sensitive information such as database details, API keys, or user credentials. Use generic error messages that do not reveal internal system details to potential attackers. 5. Implement Retry Logic for Transient Errors For errors that are likely to be transient, such as network timeouts or service disruptions, consider implementing retry logic on the client side. However, retries should be implemented judiciously to avoid overwhelming the server with repeated requests. 6. Document Common Errors Provide comprehensive documentation that includes common error codes, messages, and their meanings. This helps developers quickly identify and troubleshoot common issues without needing to contact support. 7. Use Logging and Monitoring Implement logging and monitoring to track API errors and performance metrics. Logging helps you understand the root cause of errors, while monitoring allows you to proactively identify and address issues before they impact users. 8. Handle Rate Limiting and Throttling Implement rate limiting and throttling to protect your API from abuse and ensure fair usage. Return appropriate error codes (e.g., 429 - Too Many Requests) when rate limits are exceeded, and provide guidance on how users can adjust their requests to comply with rate limits. 9. Provide Support for Localization If your API serves a global audience, consider providing support for localization in your error messages. This allows users to receive error messages in their preferred language, improving the user experience for non-English speakers. 10. Test Error Handling Finally, thoroughly test your API's error handling capabilities to ensure they work as expected. Test various scenarios, including valid requests, invalid requests, and edge cases, to identify and address potential issues. Conclusion Effective error handling is essential for building reliable and user-friendly APIs. By following these best practices, you can ensure that your API handles errors gracefully, provides meaningful feedback to users, and maintains high availability and security. Implementing robust error handling practices will not only improve the reliability of your API but also enhance the overall user experience.
