I'm investigating the use of http-proxy-middleware / node-http-proxy as a reverse proxy. Does anyone know if this is really possible?
I've already setup http-proxy-middleware so that I can proxy a request through it (the results are displayed in an iframe), and I'm also able to modify the request headers and html results. Specifically, I'm setting the host/origin headers and rewriting the result to change embedded links so that they go through the proxy as well.
But, some links are generated by js, and rewriting javascript responses seems to be very difficult to do correctly.
Is there a way to do this without rewriting links? I.e., is there any method to configure the iframe to automatically send all requests through the proxy?
Or maybe this is not really possible, and I'd need to use a full proxy like Squid?
Thanks!
This does seem to be possible, to a limited extent. http-proxy-middleware can be configured to edit response headers and to also rewrite the response body, so that links can be rewritten to use the proxy URL. XmlHttpRequest and fetch() requests can also be intercepted to rewrite the requests to use the proxy URL.
Use of a reverse proxy should be 100% transparent to clients and your application code, with zero code changes. So perhaps it is a design problem where I can clarify requirements for you.
URL DESIGN
As an API example, I might design URLs as follows for an API:
Public URL: https://api.mycompany.com/products
Internal URL: https://productservice.internal.com:3000
Note that the public URL of the API is actually that of a route within the reverse proxy.
An internet client would only ever use the public URL. If the internal API ever returns URLs to internet clients, it needs to be configured to use the public URL.
REVERSE PROXIES
The most mature options are probably the nginx based ones, which provide both declarative routing and also the ability to write any logic you like via plugins. There are plenty of examples in Curity guides, which may make you aware of some use cases
A mainstream option is to use the proxy-pass directive to route to an internal URL. The same pattern should work for the node RP you mention, though for simple tasks no custom logic should be needed.
Header configuration is a common thing to do in the RP, eg to ensure that the component receives the original client's IP address, rather than that of the RP, but that is often optional.
MISBEHAVING BACKEND COMPONENT
Perhaps this is the root of the problem - if a website returns the internal URL, eg in redirects or image URLs, then it is wrong. Many tech stacks will have a property such as BaseUrl that fixes this.
Related
I have a problem with Domino Web Server with an XPages Application which is placed behind some reverse proxy. The problem is, the proxy forwards all requests from the URL like h2tps://organization/test_server/ to the Domino Web Server.
This makes all links in the application brocken. And I don't know how to fix it.
For example, the login attempt will be redirected by the server to h2tps://organization/names.nsf?Login instead of h2tps://organization/test_server/names.nsf?Login
Have you any idea how to fix it?
When using a reverse proxy, we recommend keeping the original URL unchanged. Because many redirects, Ajax requests, cookie are closely related to URL, if the URL changes, almost must go to modify the code.
This problem is especially serious in Domino, because in a lot of Javascript code that will be used in the absolute path, for example /names.nsf. As a comparison of Java applications in general will use relative paths (for example ../login).
The actual way to achieve URL unchanged: map the domain name of the original domino server (for example test.domino.xxx), to the reverse proxy server, and reverse proxy server via http HOST header to determine forwarded to which backend server, without the need to add additional path (for example test_server).
In IBM WebSeal example, this configuration is called virtual host junctions.
Did you create a site document on the domino Server?
I have solved the problem with some efforts.
At first I have moved the DB in the folder /test_server/.
Then I have changed all static HTML links to use the /test_server/.
With the option xsp.application.context.proxy=test_server I have changed the
paths for internal XPages and Extensions Library resources.
At the end I have to add some substitution rules on the Domino
to prevent duplicated paths like /test_server/test_server/.
Now it seems to be working well.
The proposal from the proxy team was to use url rewrite on the Web Server. It can be done with Domino without doubt, but requires to develop a DNSAPI Addon (a dll written in C). And it doesn't look for me like an easy task.
Anyway, thanks a lot for your help!
I am planning to develop a project which will have access to different services placed in different domains using ajax, so that it may get different types of data from each of them.
At the beginning I thought that due to cross-site scripting that can't be done so I would have to use a different approach or maybe use a bridge (make the calls to my server which will behind the scenes call the others) but the bridge would become a performance issue.
But then I was testing Angular using Google's API and realized that it just works. I mean, I could make AJAX calls to my localhost (though I know localhost may work just because it's localhost) using a script loaded from googleapis.com.
Now I wonder if it is possible or not to have a page with ajax calls to other domains like: mail.mydomain.com, profiles.mydomain.com, media.mydomain.com, and so on. And if so, can that be done just like that or are there any limitations? Because I remember that some years ago I had trouble doing things like that due to the cross-script block.
Just in case it helps, I'm planning to use Angular to get the data and paint it over the views.
Thanks.
Use JSON-P for cross domain AJAX. http://json-p.org/
Yes, it has limitations, but can be relieved easily.
Set HTTP header "Access-Control-Allow-Origin" to "*" does it.
Im getting different counts for google PlusOne for https and http protocols.
Has anyone experienced this behaviour and have any suggestions as to resolve it.
I am using the typical implementation shown here.
I also found this link regarding canonical urls but I dont think this is relevant in this case as I have no alternative canonical url only repeated content served on the 2 different protocols.
Pages referred by different URLs are different. One can serve different content via HTTP and HTTPS. So if you want to have the same counter, you need to specify the canonical URL (with or without https, you decide) in counter parameters.
As part of a product we are deploying, clients need to access a remote API on our servers to access content and data. Nonetheless, for some reasons and some clients, a solution where the entire page is on our servers is not desireable (reasons include: control over design, but mostly SEO, and them wanting this content to be available under "their domain")... A script that accesses the API server-side is not desirable due to other issues.
My idea follows (and I will point out its flaws so others can please suggest alternatives):
1) Make a simple script to be hosted on the clients server which will obtain all traffic from a certain URI path (catch-all script, similar to any framework router). so /MyApp/*. This script would always return a single code, a "loader javascript and styling"...
2) Through javascript returned from the script above, extract the URL, and process the URI after the desired path /MyApp/[*] and send it to an external call with JSONP or CORS regular ajax, the return is then styled appropriately and displayed.
With this, a url such as /MyApp/abc and /MyApp/def would have the same html/js in the browser source, but the JS would load different data from the ajax call, therefore showing different content...
This would seem like a good solution, the only drawback is that from my understanding, google and other searchengines wouldnt ever be able to access the content from abc and def, they would only access the "loader javascript and styling" (obvious enough, they arent going to be running the JS)...
So this is better than #! in that it wouldnt screw with URLs, but would still be depending on JS, so not search engine friendly...
Due to server restrictions, I'd much rather have a simple "catchall" page, and have the API called from the client-side than have to impose minimum requirements such as curl, etc... plus I'd have access to the end-user ip address more easily this way (although I could make a more elaborate proxy - which would make installing it much harder on clients' servers)...
Is there a way of achieving this without conneting to the api from the server-side?
The easiest method of doing this IMO is to have an AJAX controller (assuming MVC design) to handle all remote requests. Have each action in your controller return JSON, and then you have easy access to the data with a serverside call.
Otherwise you are using the #! solution (which you don't like, and rightly so..), or using JSONP (a hassle as well).
i have two servers a main site and a static server.
i want to get a file's content from ajax in runtime, which is stored in static server.
obviously cross domain problem will occur.
so what i am trying to do is storing that ajax .js in the static server, so that calling the local file wont be a problem.
but after i include that js file from static, still that problem remains...
Any solutions?!
n't use X domain Ajax Requests. Create a "proxy" on your own server (domain) then forward the call to the other domain, cache it, check for security issues and send it back to client again...
Depending on the information you want your ajax request to recieve you could always use something like jsonp which could have the cross-site call.
try looking here for some examples:
http://remysharp.com/2007/10/08/what-is-jsonp/
Take a look at EasyXDM. It's a library which wraps cross-browser quirks and provides an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser (e.g. postMessage if available, other mechanisms if not).
Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them). But you don't need any server-side code changes.