Proxy as a service

Azure Functions is a lightweight way to quickly expose an API, the “serverless” way.

Now I wanted to proxy another API to clients (to avoid having to expose the API key and have a future extension point), so I reached for Azure Functions again. Just create an HTTP trigger to act as the proxy and forward calls to the other API, right?

Apparently this use case is already handled by Azure Functions Proxies

You literally just declare the proxy and it works, nice.
Add a proxies.json in the root of your Azure Functions app (assuming you are programming it, if you use the portal, just go to the Proxies node and follow the self -explanatory UI)

{
  "$schema": "http://json.schemastore.org/proxies",
  "proxies": {
    "name_your_proxy": {
      "matchCondition": {
        "methods": [ "POST" ],
        "route": "/api/proxy_call"
      },
      "backendUri": "https://the-api-you-want-to-proxy.com",
      "requestOverrides": {
        "backend.request.headers.example-secret": "dummy-secret" 
      }
    }
  }
}

Publish this and you can call your Azure Functions app on /api/proxy_call, which forwards the call to https://the-api-you-want-to-proxy.com while adding the header with the secret you don’t want to expose to your clients. Simple!

Theme music for this blog post

Advertisements
Proxy as a service

target _blank security issue

I think this is an old issue, but I only just learned about it via a lint error react/jsx-no-target-blank I got in a react project.

Apparently a new window opened by a link, has access to the originating window object.
When this new window is another (malicious) site, it has access to the dom of the site that linked it.

Adding rel=”noopener noreferrer” to your anchor tag mitigates this risk.

Check this much better quick decent explanation:
https://mathiasbynens.github.io/rel-noopener/

Theme music for this blog post

target _blank security issue