I think I'm doing something completely the wrong way.
I have an Nodejs server running that read in a DB and serve with express some data via http locally (it has to only be accessed locally). It sends the data on localhost on some port (8080 for example). Then I have an angular app on the server that get these datas from an http request on localhost:8080 and display them. The angular app runs locally on localhost:4200.
I was building the entire stuff on my computer and that was working perfectly (I have no problem with CORS). Then I deployed it on a server, and I accessed it via ssh port forwarding. Basically I forward localhost:4200 on the server via ssh on my local computer on localhost:8090.
And my problem is that, when loading and executing the angular app in my browser via port redirection, it's doing a get request to localhost:8080. So it's trying to communicate with the localhost it's running on, which is the client itself.
If you understood my spaghetti situation, there is actually a dirty solution : redirect localhost:8080 on the server to localhost:8080 on the client.
Is there any way to do the get request server side and not in the client's browser so that localhost correspond to the server? Is there a better way to do what I'm trying to do?
I can sum up by : How can you access another local service on localhost on the server with angular app since it executes in the client browser and localhost will refer to client localhost.
Try to use any web server (such as nginx or apache2 or etc.) in your server and make use of proxy and reverse proxy with your node application, it will work
angular2-router-and-express-integration
I am using this app https://github.com/nice-table/bitmex-scaled-orders to connect to testnet.bitmex.com through the api to place orders. I am running the app on Windows in node.js. It looks like the app starts a websocket on port 1337 and a bitmex proxy on port 8000. The app uses a GUI through the browser that you connect to through localhost:3006.
I have a proxy server set in Windows settings. I am unable to access localhost:3006 without the bypass proxy checkbox checked which makes sense. However, when I check the box, it seems as though outgoing traffic to bitmex is also bypassing my proxy. I am able to know because when I put wrong proxy info, the app still connects. Shouldn't this checkbox only apply to local traffic? Is there any way I can make this app use my proxy?
This can be used for testing, make sure the testnet is selected in the app
key ID: 9I0Ez-z-a8wAgM-IB03OMLg0
key secret: OzanemIvHP368THbeGjT6by5bABmYWIXQvAXILX6oumQpipY
I am illiterate when it comes to this stuff please let me know if theres more info I can provide. I tried contacting the author on github but no answer.
it's a little bit weird, but a 3rd party application has an embedded IE with a configureable static URL. This IE calls my webserver (nodeJS). The application has no parameter for the url, so I have a simple nodeJS app which starts with the login of the user and connect to the webserver (websocket). This app is able to see the dynamic parameter of the 3rd party app by looking in the user registry. Both together I would the information to bring the right data to the embedded IE. But how can the webserver relate the IE request to the websocket connection of the "registry app". The websocket app knows the NT username and many more, but the IE only sends a simple http request.
If it wasn't a terminal-services, I would the IE run over the a local webserver, which would forwarding the request plus the registry data to the real webserver (like a proxy). But it's a terminal-services, so there is the port blocking problem. Or is there a way to bind a server to a kind of "virtual per user ip" on the same port?
//Jonny
I have a website behind cloudflare. I need to enable websockets over SSL without turning off cloudflare support. I have a PRO plan and hence won't get the new websocket support. I am using Nginx to proxy a SSL connection to a web socket running on a node server. Now, I read somewhere that cloudflare could work with approved ports would support websockets. Hence, I'm using 8443 for the Nginx port and another port for the node server. Using wscat it returns a 200 error.
$ wscat -c wss://xyz.com:8443
error: Error: unexpected server response (200)
I know that the websocket is expecting a 101 code. However, if I visit https://xyz.com:8443, I can see the page displayed by the node server telling me proxy is working. Also, once I turn off cloudflare support, the websocket starts working. Any clues to get this working. I know I can create a subdomain but I'd prefer running the websocket behind cloudflare.
If you're trying to access this through CloudFlare's network you'd need to explicitly have web sockets enabled on your domain before they will work -- regardless of the port. As in, even if the port can pass through our network, that won't automatically mean that web sockets will be enabled or accessible on your domain.
You can try contacting our support team to request an exception to see if they can enable it for your domain, but typically this is still only available at the business and enterprise levels.
Disclaimer: I work at CloudFlare.
Sorry if it is a duplicate, as I am not a security nor network expert I may have missed the correct lingo to find information.
I am working on an application to intercept and modify HTTP requests and responses between a web browser and a web server (see how to intercept and modify HTTP responses on server side? for the background). I decided to implement a reverse proxy in ASP.Net which forwards client requests to the back-end HTTP server, translates links and headers from the response to the properly "proxified" URL, and sends the response to the client after having extracted relevant information from the response.
It is working as expected, except for the authentication part: the web server uses NTLM authentication by default, and just forwarding requests and responses through the reverse proxy does not allow the user to be authenticated on the remote application. Both the reverse proxy and the web application are on the same physical machine and are executed in the same IIS server (Windows server 2008/IIS 7 if that matters). I tried both enabling and disabling authentication on the reverse proxy app with no luck.
I have looked for information about it, and it seems to be related to the "double-hop problem", which I do not understand. My question is: is there a way to authenticate the user on the remote application through the reverse proxy using NTLM? If there is none, are there alternative authentication methods I could use?
Even if you don't have a solution to my problem, just pointing me to relevant information about it to help me get out of the confusion would be great!
I found what the problem was (and it is NTLM): in order to have the browser asks the user for its credentials, the response must have a 401 status code. My reverse proxy was forwarding the response to the browser, so IIS was adding a standard HTML code to explain the requested page cannot be accessed thus preventing the browser from asking credentials.
The problem was solved by removing the response content when the status code is a 401.
With all due respect I have for the one that answered that some years ago, I must admit this is plainly false. The problem was indeed solved AFTER removing the response content when the status code is a 401, but it had none to do with the initial problem..
The truth is that windows authentication was made to authenticate people over local windows networks, where no proxy server is present or even needed.
The main problem with NTLM authentication is that this protocol does not authenticate the HTTP session but the underlying TCP connection, and as far as I know there is no way to access it from asp code.
Every proxy server I tried broke NTLM authentication.
Windows authentication is comfortable for an user because he won't ever need to enter your password to whatever application may lie in your intranet, frightening for a security guy because there is an auto-login without even a prompt if the site domain is trusted by IE, shocking for a network administrator because it melts the application, transport and network layer into some "windows ball of mug" instead of just plain http traffic.
NTLM won't work if the TCP packets are not forwarded exactly as the reverse proxy received > them. And that's why many reverse proxy doesn't work with NTLM authentication. (like nginx) > They forward HTTP requests correcty but not the TCP packets.
Nginx has the functionality to work with NTLM authentication. Keepalive needs to be enabled which is only available trough the http_upstream_module. Additionally in the location block you need to specify that you will be using HTTP/1.1 and that the "Connection" header field should be cleared for each proxied request. Nginx config should look something like:
upstream http_backend {
server 1.1.1.1:80;
keepalive 16;
}
server {
...
location / {
proxy_pass http://http_backend/;
proxy_http_version 1.1;
proxy_set_header Connection "";
...
}
}
I scratched my head for quite some time with this issue but the above works for me. Note that if you need to proxy HTTPS traffic, a separate upstream block is deemed necessary. To clarify a bit more, "keepalive 16;" specifies the number of simultaneous connections to the upstream your proxy is allowed to keep. Adjust the number as per the expected number of simultaneous visitors on the site.
Although this is an old post, I just want to report that it works for me quite well with an Apache2.2 reverse proxy and the keepalive=on option. Obviously, this keeps the connection between the proxy and the SharePoint host open and "pinned" to the client<>proxy connection. I don't exactly know the mechanisms behind this, but it works fairly well.
But: Sometimes, my users encounter the issue that they're logged in as another user. So there seems to be some mixing-up through sessions. I will have to give this some further testing.
Solution for everything (in case you have a valid, signed SSL certificate): Switch IIS to Basic Auth. This works absolutely fine, and even Windows (i.e. Office with SharePoint connection, all WebClient-based processes etc.) won't complain at all.
But they will when you're just using http without SSL/TLS, and also with self-signed certificates.
I confirm that it works with "keep-alive=on" on apache2.2
I examined frames with Wireshark, and I know why it doesn't work. NTLM won't work if the TCP packets are not forwarded exactly as the reverse proxy received them. That's why many reverse proxies, like nginx, don't work with NTLM authentication. Reverse proxies forward HTTP requests correctly but not the TCP packets.
NTLM requires a TCP reverse proxy.