Azure APIM URL without API and Operation - azure-api-management

I want to serve a request by APIM policy only, is it required to have API and operation for the same ?
for example
https://myapim/myapi/myoperation
I will serve this request from policy itself by calling few external APIs, do i need to create myapi API and myopration as blank operation ? or is there anyway to handle this ? currently i am getting 404 from APIM before reaching to policy code.

When you create api in APIM, it will ask you to input your backend url like below screenshot.
And then when you create operation, if you input /myoperation/ into the "URL" box like below:
It will request https://your-backend-url/myoperation in the backend, but your backend url is https://your-backend-url. So you may get 404 error. To solve this problem, you can just input / into the "URL" box when you create operation.

I had to create a dummy operation in my API by this my policy is getting executed and serving the request.

Related

create 2 different endpoints in azure APIM for same function app

I have single azure function app. I want to create 2 different API endpoints in Azure APIM. How I can do that?
According to some test, it seems we can't implement the requirement by adding an operation in api management because it will show error message Operation with the same method and URL template already exists.
And if we use some other methods such as clone the operation, it will also fail with 404 error because the URL field will change and can not match the function url.
So I think you can just add another api in your api management to implement the requirement (shown like below screenshot).
The two APIM endpoints should be:
https://huryapim.azure-api.net/huryFun1/HttpTrigger1 and https://huryapim.azure-api.net/huryFun2/HttpTrigger1. Both of them request the same azure function url in backend.

How to use azure api management to do custom access token check and enrich data in request

All the incoming request to api management will have a token in a header, before backend service is hit token has to be verified. To verify token a GET tokenVallidationApi is to be hit and the response will tell us whether the token is valid or not. If the response exists for token validation , we have to take out few entries from response and enrich the body/header to hit the backend api. I am very new to api management tool and just figuring out how can we achieve this with azure api management?
This is possible. You would have to implement your policies like something below
1. Validate Token
For this, you would first call the validation endpoint using send-request. You could also implement caching using value caching policies for multiple requests.
The doc also highlights how you can extract value from the response body.
2. Transform Body & Headers
For headers, you would use the set-header policy and for the body, you would use the set-body policy.

How to debug server-side `redirect_uri_mismatch` error from Google Signin

I'm attempting to use Google Sign-In with a firebase function following Google's documentation for Google Sign-In for server-side apps, however I'm running into a redirect_uri_mismatch error (unlike the examples in that documentation, I am using Google's nodejs SDK).
The general flow I'm following is to use google's javascript SDK to request an offlineAccessCode() from a user, send that access code to the server (firebase function), use the access code to get an access token and refresh token, and save the refresh token for later use (this is the flow outlined in the documentation).
It might seem like the meaning of the term redirect_uri_mismatch is self-explanatory, but, as stated in the linked documentation, The Authorized redirect URI field does not require a value. Redirect URIs are not used with JavaScript APIs. That line comes from the section "Step 1: Create a client ID and client secret" and is explaining how to configure the OAuth client credentials. This is the only time in the documentation that a redirect uri is mentioned, and there is no indication that a redirect URI is needed when the server uses the authorization code to fetch an access token.
Indeed, the concept of a redirect uri doesn't seem to make sense in the context of a cloud function using an access code obtained from a client. If the server needs to supply a matching redirect_uri as the javascript client (which doesn't seem to be specified anywhere), I'm not sure what redirect_uri the javascript client uses.
So with that background, does anyone have any idea how to solve this redirect_uri_mismatch error?
Or, more generally, any pointers on implementing this auth flow (my cloud function is written in javascript using the google nodejs sdk). I'm finding it very hard to debug this issue.
Update
I realized that the reason why the error message says redirect_uri_mismatch is because I had been testing various values as redirect_uri. When I remove the (optional) redirect_uri param from the request, the response from google's servers is invalid_request: Missing parameter redirect_uri. So google's making it clear that it wants a redirect URI, even as the documentation seems to imply that it isn't necessary for this auth flow. As a larger problem, the documentation doesn't seem to describe how to set up a redirect URI for an auth flow on a single page app.
Ah HA! The answer (as given in this other S.O. answer) is to set the redirect_uri to "postmessage" on the server (firebase function in my case). I have no idea where this answer came from (i.e. I haven't been able to find it in the docs), but it works.

How to secure my api key?

I want to use from my android/ios app the autocomplete api. For this I need to call url like:
https://maps.googleapis.com/maps/api/place/autocomplete/json?input=paris&key=<myapikey>
the problem is: What can make that someone else will not extract from my app my api key and use it for his own purpose ? It's important because at the end it's me who will be billed by google for the usage ...
Your intention is to call a Places API web service. Google Maps web services support only IP address restrictions.
You can check what type of restriction is supported by each API on the following page:
https://developers.google.com/maps/faq#keysystem
In order to protect an API key that is used with your sample request you should create an intermediate server and send your requests from this server. So your application should send request to intermediate server, intermediate server should send Places autocomplete request with protected API key to Google and pass response back to your app. In this case you can use an IP address of your intermediate server to protect unauthorized access with your API key.
I hope this helps!
What if you create and intermediate server and create a token for each single user, and also create a monitoring service which block suspicious behavior?
for example, a normal user would request x times/per day || hour || ...
Or
when a user runs application for the first time, application receives the [encrypted api + decryption key] and store them to a safe place like keychain(for iOS)
As I know, if you request directly to google-map-api there is always a way to sniffing packets.

How to forward all Options requests to backend server with Azure Api Management

Is it possible to create a single policy that will forward all Options requests to the backend server? The only way I have figured out how to do this is by creating a new Options operation for each endpoint. That seems like a lot of unnecessary work since I want all options requests to be forwarded to the backend.
How can I create a single policy to forward all Options requests to the backend?
I don't think that is currently possible, so your only options are:
Create a separate OPTIONS operation in each endpoint.
Set up CORS (https://msdn.microsoft.com/library/azure/7689d277-8abe-472a-a78c-e6d4bd43455d#CORS) policy on a product or global level, so that OPTIONS requests would be served by APIM and not forwarded to backend at all.
Actually it is, operation template support wildcard /*
I am trying this, but since our API requires an SubscriptionKey, it is still not working. Since ApiMgmt will return 401 for options request, since browsers dont send the SubscriptionKey header.
Would be nice with the possibility to open single operations...
https://feedback.azure.com/forums/248703-api-management/suggestions/19450117-feature-to-ignore-api-management-subscription-key