We got a lot of failed requests throwing from Get /echo/resource in the Azure application insights, I could not find it in our .net projects (for the rest failed APIs I can find them in the code), also When I launch the project in the browser, with using the developer tool, this echo API is not in API lists under Network tab. Below are the screen shots captured from the application insights:
APIs error list sample
transaction detail of echo/resource error
I googled and get the basic info about what is echo, but not quite sure if we are not using it in the .net project, where it comes from?
Based on the path of URL, it seems to be coming from the API Management placed before your REST API application. APIM has the default Echo API for testing purposes. This API seems to have been configured/exposed or is being used to route the request to the backend App itself.
Related
We have integrated Azure Application insights with our bot built using Azure bot framework using node.JS and typescript. Everything looks fine and we can see telemetry data flowing in.
In the failures section, we can see Operation name "GET /api/messages" showing repeated times - one failed call (405) and one success call (200).
But we have no GET operation being done on "/api/messages" in our code. We only have "POST" operations.
We are unable to understand why telemetry shows GET operation and one as failed and one as success.
Any help is appreciated.
The operation_SyntheticSource field of request telemetry is often used by microsoft / azure to indicate traffic that is generated by infrastructure or bots. Examples are health requests, keep alive traffic, spider bots.
There are options to filter out telemetry, so it is possible to filter out telemetry cause by synthetic traffic. See the docs.
Telemetry processors can be configured using DI.
Scenario: Auth0 Single Page application client. .NET Web API and Angular SPA both configured to use this client. Works great.
I'd like to add Azure API Management as a layer in front of the API. Have set up the API in the Management Portal, updated SPA to call API, tested calls from SPA, works great.
Now, I'd like to configure API Management Portal with the right security settings such that people can invoke API calls from the Developer Portal. I've used this [https://auth0.com/docs/integrations/azure-api-management/configure-azure] as a guide.
Where I'm at:
From the Developer portal, I can choose Authorization Code as an Auth type, go through a successful sign-in process with Auth0 and get back a Bearer token. However, calls made to the API always return 401. I think this is because I'm confused about how to set it up right. As I understand it:
either I follow the instructions and setup a new API client in Auth0, but if that's the case then surely it's not going to work, because tokens generated from one client aren't going to work against my SPA client? (or is there something I need to change to make it work)
or, how should I configure Azure API Management to work with a SPA application. (this would be my preferred method, having two clients in Auth0 seems 'messy'). But, don't I need an 'audience' value in my authorization endpoint URL? How do I get that?
If anyone has done this, would very much appreciate some guidance here.
Well, I didn't think I'd be back to answer my own question quite so soon. The reason is mostly rooted in my general ignorance of this stuff, combined with trying to take examples and fuse them together for my needs. Posting this to help out anyone else who finds themselves here.
Rather than take the Single Application Client in Auth0 and make it work with Azure API Management, I decided to go the other way, and make the non-interactive Client work with my SPA. This eventually 'felt' more right: the API is what I'm securing, and I should get the API Management portal working, then change my SPA to work with it.
Once I remembered/realised that I needed to update my audience in the API to match the audience set in the Client in Auth0, then the Management Portal started working. Getting the SPA to work with the API then became a challenge: I was trying to find out how to change the auth0 angular code to pass an audience to match the one the API was sending, but it kept sending the ClientID instead. (by the way, finding all that out was made easier by using https://jwt.io/ to decrypt the Bearer tokens and work out what was happening - look at the 'aud' value for the audience.
In the end, I changed my API, in the new JwtBearerAuthenticationOptions object, the TokenValidationParameters object (of type TokenValidationParameters) has a property ValidAudiences (yes, there is also a ValidAudience property, confusing) which can take multiple audiences. So, I added my ClientID to that.
The only other thing I then changed (which might be specific to me, not sure) is that I had to change the JsonWebToken Signature Algorithm value in Auth0 for my non-interactive client (advanced settings, oAuth tab) from HS256 to RS256.
With all that done, now requests from both the API Management Portal, and my SPA work.
Curious to know if this is the "right" way of doing it, or if I've done anything considered dangerous here.
Since you're able to make the validation of the jwts with the .Net API work, Only few changes are actually necessary to get this working with Azure API Management.
In API management,
Create a validate-jwt inbound policy on an Operation (or all operations)
set the audiences and issuers the same as what you've used with your .NET web api. (you can check the values in Auth0 portal if you don't know this yet)
The important field that is missing at this point is the Open ID URLs since auth0 uses RS256 by default. The url can be found in you Auth0 portal at: Applications -> your single page application -> settings -> Scroll down, Show Advanced Settings -> End points. Then copy the OpenID Configuration
Here's the reference for API management's requirement for JWT tokens
optional reading
I have a ASP .NET Core MVC web service hosted in Azure to which I would like to POST data. I am able to post from Postman so I know the service is working and the required format of the request. I have another client sending what I believe to be the same post request but somewhere the request is failing. I would like to confirm the requests are reaching the service and if so see exactly what the request looks like when it gets there so I can compare to the working version. I have enabled web logs on the service but what info I can find as a result does not provide detail of the failed request. I also downloaded logs via the Cloud Explorer in Visual Studio but again I cannot see the content of the request to troubleshoot. I'm sure I'm not utilizing the logging fully but I'm not familiar enough with Azure web services to know what I'm missing and am having trouble finding guidance on the web. Perhaps it is not possible to capture the failed post data for security reasons? If so then presumably I need to hook up a debugger and see if I can step through the processing of the request.
What would be the most effective way to troubleshoot failed web service requests?
After further research I found an excellent reference on troubleshooting Azure Web Services at https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-dotnet-troubleshoot-visual-studio. Using the information and tools covered there I was able to resolve my problem which ultimately proved to be a problem sending the request. Watching the web server logs it became clear the client's request was never reaching the server.
I have built a asp.net app that successfully accesses o365 exchange with an App Only Token and Graph. I am now trying to access a specific user's OneDrive for Business files with the same token and a Get request similar to the following:
https://mycomp-my.sharepoint.com/_api/v2.0/drives/simon#mycomp.com/items
but I get the following error:
3001000;reason='There has been an error authenticating the request.';category='invalid_client'
Any idea what is the cause of the error?
It's possible to do app-delegated access to OneDrive for Business today using the direct API endpoint and the Sites.ReadWrite.All app-delegated permission scope in AAD. I'd consider it more "in preview" than supported, so Yina's answer is technically correct. I'm still getting the documentation for how build an app finalized, but we'll be publishing something soon.
Andrew Connell has a good blog post about how to get this setup, available here: http://www.andrewconnell.com/blog/user-app-app-only-permissions-client-credentials-grant-flow-in-azure-ad-office-365-apis
Use of the OneDrive API is possible using this same method.
App Only access to a user's OneDrive is not supported via Microsoft Graph at this point in time.
I have a custom Windows service developed in C#.NET that synchronizes users' Google calendars with an internal calendar.
Per the Google Calendar API documentation, I'm using the below code. I believe this is referred to as the ClientLogin method which may or may not be advised (I've found conflicting information in the Google documentation).
CalendarService service = new CalendarService("Your app name");
service.setUserCredentials("username", "password");
This worked fine in testing. Now that things have moved to production, I'm receiving errors such as "The user has exceeded their quota, and cannot currently perform this operation" and "User has modified too many events today. Please try again tomorrow." This began more than a day ago and has remained as such.
I've researched this considerably and am still confused on a few points. Any help would be greatly appreciated.
What is the daily quota per user?
Are the (really low?) quotas there because an API key isn't being used by my application?
If I were to use an API key, which approach would I use for a Windows service in which I have the usernames and passwords for the Google users? - Simple API, OAuth2, Service Account, etc.
FYI: I am using the API .NET library provided by Google. If I should be using a particular authentication approach, I would appreciate a sample illustrating the implementation using the .NET library provided via Google.
First of all you definitely don't use the latest version of the library. You can download it from NuGet. You should download the following two packages:
https://www.nuget.org/packages/Google.Apis.Calendar.v3/
https://www.nuget.org/packages/Google.Apis.Authentication/ (be aware that in the next release we are going to improve the OAuth2 flows significantly, and support WP, Windows 8 application).
Regarding your questions:
1-2) Calendar API supports 100,000 requests/day. You can find that information in the Google API Console in the services tab.
3) Definitely OAuth2. Read more here and here.
You can find code samples with the current implementation of OAuth2 in our samples repository (https://code.google.com/p/google-api-dotnet-client/source/browse/?repo=samples)