Accessing an API Behind a Firewall
The following Anypoint Platform browser tools route calls to your API through a reverse proxy by default:
The browser can then get resources from your API and Anypoint Platform browser tools undeterred by the same-origin restriction policy.
When a browser makes an HTTP request to a domain and that domain returns a page, that page is the origin domain. Any scripts running in that page are allowed to make additional requests back to the origin domain only. If a script attempts to make a request to, or load resources from a different domain, the response is normally blocked to prevent the script from gaining access to other sites you visited.
If your API is located behind a firewall that prevents inbound requests, the API is unreachable. You won’t be able to use API Console, API Designer, or API Notebook unless you properly set up CORS (Cross-Origin Resource Sharing) to allow users and/or client requests to access the tools whose resources are located outside your origin domain.
Alternatively, for testing purposes, you can use one of the following ways to avoid same-origin restriction:
Also, consider disabling mixed content blocking.
Releasing an API to production without properly addressing a security model to handle cross-origin resources can potentially enable dangerous Cross-Site Request Forgery (CSRF) attacks, among other threats that can harm clients and users accessing your resources.
If you are testing your implementations in a local, or test environment, you can apply any of the methods described below to be able to access the online browser tools provided by Anypoint Platform.
Do not use the methods described below for a production release of your implementation.
If you cannot implement CORS for your API, another possible solution to an unreachable API is to disable the same-origin restrictions in your browser. Each browser handles these restrictions in a unique way; for example, after launching Google Chrome from the command line to disable the same-origin restrictions and then closing Chrome, your next Chrome session automatically re-enables the restrictions. Internet Explorer’s settings persists across application sessions, so you need to change your Internet Options manually. Mozilla Firefox doesn’t currently support a way to disable same-origin restrictions without using a custom build of the browser.
Make sure you understand the potential security implications of changing browser security settings. You should only use these options for testing on your own web pages because the browser can become vulnerable to malicious scripts and other potential threats.
Open a new Terminal window, paste the following line, and then press Enter:
open -a Google\ Chrome --args --disable-web-security.
Open a new Command Prompt window, navigate to the location of the Chrome executable (Chrome.exe), paste the following line, and then press Enter:
You cannot disable the same-origin restrictions in Firefox without using a custom build of the browser source code.
Open Internet Properties, click the Security tab, and then click the Custom level button in the Security level for this zone section.
A Security Settings dialog appears. Scroll down the list of security settings and locate the Miscellaneous section, and select Enable for the Access data sources across domains setting.
If you use the Anypoint Platform tools in an environment that blocks inbound requests using a firewall, bypass the proxy as described in this section.
Go to the API Designer for your API. On the right pane, check that the API is behind a firewall, which bypasses the proxy.
Go to the API Notebook for your API. In the initial code cell that creates a client, create a new code cell with the following code to set a new proxy configuration on the client:
API.set(client, 'proxy', false);
In the line above,
client represents the name of your client that you used when you called
API.createClient(). For example:
API.createClient(<name of client>, …);
Combining these two lines together, the following example creates a new client and then bypass the default proxy:
API.set(myClient, 'proxy', false);
When an HTTPS web page retrieves resources from an unsecured HTTP endpoint, the resulting blend of secure and unsecure content is called mixed content. Browsers block such mixed content and display an error because of the security implications. For example, mixed content introduces the possibility that a man-in-the-middle attacker could have injected malicious site resources (such as scripts) during the request and response. You may encounter this issue when using the API Manager, and it’s important to understand how you can mitigate it.
The API Manager browser tools (API Console, API Designer, and API Notebook) are hosted on an HTTPS endpoint. All requests and responses sent between your browser and the platform’s servers are encrypted using SSL. In addition, if you’re using the default server-side proxy generated by the tools instead of bypassing the proxy, the proxy makes requests to your API and encrypts the responses through SSL so that they can be displayed in the browser without triggering a mixed content error.
If you’ve disabled the platform’s server-side proxy, any requests to your API are no longer routed through this proxy and are instead made directly to it. This situation isn’t a problem if your API resides at an HTTPS endpoint, because all communication between the browser and the requested resources is encrypted using SSL. However, if your API has an HTTP endpoint, the API Manager browser tools makes requests to the unsecured HTTP endpoint and your browser blocks the resulting "mixed content" — a mix of the browser tool’s HTTPS (secured) content and your API’s HTTP (unsecured) content.
Each browser presents mixed content errors in slightly different ways, as described in the following support pages.