Api behind Basic authentication and NTLM authentication

Hi, I have api on iis server behind basic windows authentication and i cannot use cors. So I tried to use this module but however I configure it I cannot log into api and I get 401 every time

I tried

    server.middleware = proxyMiddleware(
        '/api',
        {
            target: 'API_HOST',
            logLevel: 'debug'
        }
    );

    server.middleware = proxyMiddleware(
        '/api',
        {
            target: 'API_HOST',
            logLevel: 'debug',
            auth: 'LOGIN:PASS'
        }
    );

    server.middleware = proxyMiddleware(
        '/api',
        {
            target: 'http://LOGIN:PASS@API_HOST',
            logLevel: 'debug'
        }
    );

Hi, I haven't used the auth option personally yet.

the auth option is provided by the underlying http-proxy library.
Did a search in their https://github.com/nodejitsu/node-http-proxy/tree/master/examples, but I could not find any examples how to use the auth option.

But I did found a unit test:
https://github.com/nodejitsu/node-http-proxy/blob/302d981dd2cf06dbf751b1f64e3dfea08d0f9476/test/lib-http-proxy-passes-web-incoming-test.js#L303

Their unit test looks like the 2nd case you've provided.

Is 'API_HOST' really your target?
the target should include the http: or https: protocol

You could try setting changeOrigin to true and see if that helps.

server.middleware = proxyMiddleware(
  '/api',
  {
    target: 'API_HOST',
    logLevel: 'debug',
    auth: 'LOGIN:PASS',
    changeOrigin: true
  }
);

Yep API HOST is really my target, when i go to localhost:3000/api uri directly in the browser i get 401 error page and requests are forwarded to correct url but i cannot authorize.
i get something in header like:

 connection:close
 content-type:text/html
 date:Wed, 25 Nov 2015 06:53:58 GMT
 server:Microsoft-IIS/7.5
 Transfer-Encoding:chunked
 www-authenticate:Negotiate, NTLM
 x-powered-by:ASP.NET

from browse ajax request:

 access-control-allow-credentials:true
 access-control-allow-headers:Origin,X-Requested-With,Content-Type,Accept
 access-control-allow-methods:GET,HEAD,POST,PUT,DELETE,OPTIONS
 access-control-allow-origin:http://localhost:3000
 connection:close
 content-length:1293
 content-type:text/html
 date:Wed, 25 Nov 2015 07:00:03 GMT
 server:Microsoft-IIS/7.5
 www-authenticate:Negotiate, NTLM
 x-powered-by:ASP.NET

http-proxy-middleware uses http-proxy to do the actual proxy work.

This is what I found in their NTLM authentication example:
https://github.com/nodejitsu/node-http-proxy/blob/master/examples/http/ntlm-authentication.js

You'll have to modify the headers.
The http-proxy proxyRes event is exposed via the http-proxy-middlware option: onProxyRes.
Example: https://github.com/chimurai/http-proxy-middleware/blob/master/recipes/onProxyRes.md

If I combine the two examples you'll get this config:

var proxyMiddleware = require("http-proxy-middleware");

var onProxyRes = function (proxyRes, req, res) {
     var key = 'www-authenticate';
     proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');
};

var options = {
    target: 'API_HOST',
    logLevel: 'debug',
    auth: 'LOGIN:PASS',
    onProxyRes: onProxyRes
};

var proxy = proxyMiddleware('/api', options);

Let me know if this works.

If it doesn't, you might want to ask the question at: https://github.com/nodejitsu/node-http-proxy/issues; since the authentication part is handled by the http-proxy library.

I can see some progress for

    var onProxyRes = function (proxyRes, req, res) {
        var key = 'www-authenticate';
        proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');
    };

    server.middleware = proxyMiddleware(
        '/api',
        {
            target: 'API_HOST',
            logLevel: 'debug',
            auth: 'login:pass',
            onProxyRes: onProxyRes
        }
    );

right now on going on localhost:3000/api is infinite authorization popup, i will ask on the other project as You suggest

That sounds promising.

I noticed the usage of agentkeepalive in their example;

Did a search on the nuts and bolts of the NTLM Authentication Scheme:
~~http://www.innovation.ch/personal/ronald/ntlm.html~~
https://web.archive.org/web/20210126065105/http://www.innovation.ch/personal/ronald/ntlm.html

NTLM Authentication Scheme for HTTP

Keeping the connection alive

This scheme authenticates connections, not requests. This manifests itself in that the network connection must be kept alive during the second part of the handshake

This explains why 'keep alive' is needed.

Updated configuration:

var Agent = require('agentkeepalive');
var proxyMiddleware = require("http-proxy-middleware");

var keepaliveAgent =  new Agent({
    maxSockets: 100,
    keepAlive: true,
    maxFreeSockets: 10,
    keepAliveMsecs:1000,
    timeout: 60000,
    keepAliveTimeout: 30000 // free socket keepalive for 30 seconds
});

var onProxyRes = function (proxyRes, req, res) {
     var key = 'www-authenticate';
     proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');
};

var options = {
    target: 'API_HOST',
    logLevel: 'debug',
    auth: 'LOGIN:PASS',
    agent: keepaliveAgent,
    onProxyRes: onProxyRes
};

var proxy = proxyMiddleware('/api', options);

@zychj1

@zychj1 any progress on this issue?

@chimurai

@chimurai I run in exactly the same problem and I can confirm that the configuration provided in your comment from Nov 26, 2015 (with keepalive and header rewriting) is solving the issue. Many thanks!

@pierreconstantial

@pierreconstantial
Glad to hear the example NTLM configuration solves the issue.
Thanks for the confirmation!

@chimurai

hey @chimurai i'm having the same problem discussed on nodejs/node#8004,
I've tried to use the same configuration as here and also use the simple Agent with keepAlive option of node's http module.

I'm using webpack-dev-server with the proxy property and having a WebApi server with NTLM authentication.

Thanks ahead for your help!

@richardtallent

@richardtallent, @Perogy, I'm having this issue too. I've been dealing with it for about 3 months and I've been trying to find a pattern to it and haven't been able to come up with anything tangible. I've tried everything recommended here and spent quite a few hours digging into the requests myself. I'm using it to proxy calls through my dev server to our backend API to bypass CORS in development since CORS isn't required by our prod configuration. For some reason the last few days have been pretty unbearable, probably because we recently moved our API to the cloud.

Bump for the last four comments. I'm in the same boat. The suggestions here work sometimes, but sometimes the connection still putters out and starts throwing authentication prompts. I think it has something to do with keeping the authenticated TCP connection open. But my knowledge of server protocols is pretty limited.

I've had pretty good success with the agentkeepalive module, though for some reason it does NOT like signalr. If I try to route signalr calls through the proxy it just seems to break all the other calls and I wind up with the infinite login prompt. Maybe its an issue of websockets+ntlm?

@richardtallent

I have the same issue as @richardtallent and @Perogy. I am temporarily using the work around that restricts the maxSockets to 1, which seems to minimize the frequency of the issue but am wondering if there is any update on a resolution?

I tried this instead of just fixing the www-authenticate header. it worked intermittently like once it work and 10 times it wont :(

proxy.on('proxyRes', function (proxyRes, req, res) {
  // var key = 'www-authenticate';
  // proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');

  var headersFirstKey = {};
  var headers = {};
  for(var i = 0; i < proxyRes.rawHeaders.length; i += 2) {
    var headerKey = proxyRes.rawHeaders[i];
    var headerValue = proxyRes.rawHeaders[i + 1];

    var headerKeyLower = headerKey.toLowerCase().trim();
    headerKey = headersFirstKey[headerKeyLower] || headerKey;
    headersFirstKey[headerKeyLower] = headerKey;
    headers[headerKey] = headers[headerKey] ? headers[headerKey] : [];
    headers[headerKey].push(headerValue)
  }
  for(var j in headers) {
    proxyRes.headers[j] = headers[j];
  }
});

also tried:

require('https').createServer({
  key: fs.readFileSync('key.key', 'utf8'),
  cert: fs.readFileSync('crt.crt', 'utf8'),
  passphrase: 'test',
  rejectUnauthorized: false,
  handshakeTimeout: 100000,
  insecureHTTPParser: true,  // maybe :|
  maxHeaderSize: 10000000
},
function (req, res) {
  proxy.web(req, res);
})
.on('secureConnection', (socket) => { // to keep connection open with client
  socket.setKeepAlive(true, 10000).setTimeout(60000);
})
.listen(443);

Do not use the simple agentkeepalive use instead agentkeepalive-ntlm

https://github.com/pappan123/agentkeepalive-ntlm

Here is a quick description explaining the issue:

The main motivation for this fork from agentkeepalive was to support user specific NTLM sessions. For NTLM to work, the TCP connection has to be authorized for a user. When we use the base 'agentkeepalive', sockets are authorized using a combination of the host + port. eg yahoo.com:443. However if multiple users are trying to access a NTLM enabled site, the socket connections were getting mixed up between users. Changed the implementation to include 'host+port+cookieName' while assigning sockets

If you use the code shown by mikedevita it must work.

Here is my working configuration with Vue-cli 3 / .NET WebAPI

Install package

npm install agentkeepalive --save

Update vue.config.js

const Agent = require('agentkeepalive');

module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost',
        changeOrigin: true,
        agent: new Agent({
          maxSockets: 100,
          keepAlive: true,
          maxFreeSockets: 10,
          keepAliveMsecs: 1000,
          timeout: 60000,
          freeSocketTimeout: 30000
        }),
        onProxyRes: proxyRes => {
          var key = 'www-authenticate';
          proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');
        }
      }
    }
  }
}

This worked ! You are a gem :) <3
I was having CORS issues with .net core back end API where only windows auth could be enabled and no anonymous auth , this was causing preflight error. Your solution works perfectly with the proxy server.

Here is my working configuration with Vue-cli 3 / .NET WebAPI

Install package

npm install agentkeepalive --save

Update vue.config.js

const Agent = require('agentkeepalive');

module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost',
        changeOrigin: true,
        agent: new Agent({
          maxSockets: 100,
          keepAlive: true,
          maxFreeSockets: 10,
          keepAliveMsecs: 1000,
          timeout: 60000,
          freeSocketTimeout: 30000
        }),
        onProxyRes: proxyRes => {
          var key = 'www-authenticate';
          proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');
        }
      }
    }
  }
}

I had an issue with NTLM authentication when subsequent auth requests failed (usually after reloading the page). The issue turned out to be that Agent performed NTLM auth requests with different connections from the pool.

Changing maxFreeSockets to 1 solved the issue.

Hello -- I have information on what is causing this issue. My background isn't in the JavaScript/node world, meaning I don't have the relevant experience to go it alone. So if someone wants to chat about this issue. I'd love to tackle it together.

In short, there seems to be two issues. The first solved by

var key = 'www-authenticate';
          proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');

Is that the proxy was collapsing the www-authenticate headers into one line. Something like

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

into

WWW-Authenticate: Negotiate, NTLM

Seemingly, the browser will not begin the NTLM negotiation when it's collapsed. Even though, I think that's okay as per the standard. But the browser (I was using chrome) doesn't like it and won't reply to the challenge.

The problem with the infinite authentication dialogs comes from the real problem. Which is that NTLM negotiation requires a single TCP connection which is kept alive. The NTLM negotiation happens in 3 parts. The original request, the first challenge, and a second challenge. After the TCP socket is authenticated, as long as it stays alive each successive request will work without auth.

When we're proxying, there doesn't seem to be a connection between the incoming (from the browser), and the outgoing (to the IIS server). Why is this a problem? Because the 3 part handshake which happens in 3 separate requests through the proxy, can happen on 3 different outgoing sockets to the server. So the browser, and the server both get confused.

In order to mitigate this, I was able to set the outgoing agent configuration to use a single socket maxSockets : 1, and keep alive to true, with a long timeout keepAlive : true, timeout : 999999. This tells the http.Agent to keep the outgoing sockets alive, for a long time. The maxSockets, tells it to only use one outgoing connection. This works, for the most part. However, it's slow, and it's not quite right. Because if you look at an actual interaction between the browser and IIS server, it'll use the same socket for multiple requests. However, if you wireshark between the browser and the proxy, and the proxy and the server. You see multiple requests on several incoming sockets from the browser, and they all share the single outgoing socket (which is what makes this work) to the server.

Ideally, with NTLM the proxy should maintain the browser connection one-to-one, with the server.

Hopefully this makes sense. I empathize with everyone in this thread who's been having this issue.

We are not using http-proxy-middleware. However, maybe you can give me advice where I can ask question or maybe give me advice.

Description of what the bug is

We are developing at Windows 10. Our backend is ASP.NET Core 3.1 MVC

Windows Security dialog window pops up while I am developing an application through React. It is really annoying. We have to refresh page.

At first, this image is shown:

Then the above dialog window is replaced by the following dialog window. It requires smart card credentials:

Settings of our application

package.json looks like this:

"devDependencies": {
	"@babel/cli": "7.14.3",
	"@babel/core": "7.14.3",
	"@babel/plugin-proposal-decorators": "7.14.2",
	"@babel/plugin-transform-runtime": "7.8.3",
	"@babel/preset-env": "7.14.4",
	"@babel/preset-react": "7.13.13",
	"@babel/preset-typescript": "7.13.0",
	"@testing-library/jest-dom": "^5.16.2",
	"@testing-library/react": "^11.2.7",
	"@types/jest": "^27.5.1",
	"@types/node": "14.17.1",
	"@types/react": "17.0.8",
	"@types/react-dom": "17.0.5",
	"@types/webpack": "5.28.0",
	"@typescript-eslint/eslint-plugin": "4.25.0",
	"@typescript-eslint/parser": "4.25.0",
	"agentkeepalive": "4.2.1",
	"axios-mock-adapter": "^1.21.1",
	"babel-loader": "8.2.2",
	"css-loader": "5.2.6",
	"eslint": "7.27.0",
	"eslint-config-prettier": "8.3.0",
	"eslint-plugin-prettier": "3.4.0",
	"eslint-plugin-react": "7.23.2",
	"express": "4.17.1",
	"file-loader": "6.2.0",
	"html-webpack-plugin": "5.3.1",
	"husky": "6.0.0",
	"image-webpack-loader": "7.0.1",
	"jest": "^27.5.1",
	"lint-staged": "11.0.0",
	"prettier": "2.3.0",
	"react-hot-loader": "4.13.0",
	"rimraf": "3.0.2",
	"style-loader": "2.0.0",
	"ts-jest": "^27.1.3",
	"typescript": "4.3.2",
	"webpack": "5.38.1",
	"webpack-cli": "4.7.0",
	"webpack-dev-server": "3.11.2",
	"webpack-merge": "5.7.3"
},
"dependencies": {
	"@hot-loader/react-dom": "17.0.1",
	"@svgr/cli": "6.2.1",
	"@types/lodash": "4.14.170",
	"antd": "4.16.2",
	"axios": "^0.27.2",
	"classnames": "^2.3.1",
	"dotenv": "^16.0.1",
	"lodash": "4.17.21",
	"mobx": "6.3.2",
	"mobx-react": "7.2.0",
	"moment": "2.29.1",
	"process": "0.11.10",
	"react": "17.0.2",
	"react-base-table": "1.12.0",
	"react-dnd": "14.0.2",
	"react-dnd-html5-backend": "14.0.0",
	"react-dom": "17.0.2",
	"react-router-dom": "6.2.1",
	"react-sortable-hoc": "2.0.0",
	"ts-loader": "9.2.3"
}

In addition, we are using proxy. The settings are applied from this official React docs.

Moreover, we are using agentkeepalive.

Config of proxy file looks like this:

// development config
require('dotenv').config()
const package = require('../../package.json')
const { merge } = require('webpack-merge')
const webpack = require('webpack')
const commonConfig = require('./common')
const agent = require('agentkeepalive')

module.exports = (webpackConfigEnv, argv) =>
	merge(commonConfig(argv), {
		mode: 'development',
		entry: [
			'react-hot-loader/patch', // activate HMR for React
			'webpack-dev-server/client?http://localhost:3030', 
			'webpack/hot/only-dev-server',
			'./index.tsx', // the entry point of our app
		],
		devServer: {
			port: 3030,
			hot: true, // enable HMR on the server
			historyApiFallback: true,
			proxy: {
				'/api/*': {
					target: argv.env.mock ? '' : process.env.API_URL,
					secure: false,
					changeOrigin: true,
					agent: new agent({
						maxSockets: 100,
						keepAlive: true,
						maxFreeSockets: 10,
						keepAliveMsecs: 100000,
						timeout: 6000000,
						freeSocketTimeout: 90000, // free socket keepalive for 90 seconds
					}),
					onProxyRes: (proxyRes) => {
						var key = 'www-authenticate'
						proxyRes.headers[key] =
							proxyRes.headers[key] && proxyRes.headers[key].split(',')
					},
				},
			},
		},
		devtool: 'cheap-module-source-map',
		plugins: [
			new webpack.HotModuleReplacementPlugin(), // enable HMR globally
			new webpack.DefinePlugin({
				'process.env.appVersion': JSON.stringify(package.version),
				'process.env.isMockMode': JSON.stringify(argv?.env?.mock),
				'process.env.isDevelopment': true,
			}),
		],
	})

The current behavior

Windows Security dialog window sometimes pops up while I am developing an application through React. It is really annoying. We have to refresh page

The expected behavior

Windows Security dialog window sometimes DOES NOT POP UP while we are developing an application through React.

What we tried

We tried to set this option of axios, nevertheless the "Sign in" still pops up

axios.defaults.withCredentials = true;

UPDATE:

This is one of the URL that can return the 401 response with www-authenticate header-key:

 http://localhost:3030/api/notifications

Moreover, sometimes other methods can return 401 response. It is not always the same method return 401 response.

I was having this problem of re-authentication, even after entering my credentials. It appeared stable at some points, and not at others. Anyways, I finally found a configuration for utilizing a proxy that is communicating with an API utilizing NTLM (that works for me). Since applying this, I have yet to have the constant re-auth issue. Just posting it here in the event it helps anyone else.

Note, this was for an Angular project, but I believe http-proxy-middleware is leveraged. Note, the onProxyReq can be removed. Also, I access the webserver @ https://localhost:4200, not https://127.0.0.1.

const { HttpsAgent } = require('agentkeepalive-ntlm');

const keepaliveAgentNTLM = new HttpsAgent({
  cookieName: 'localhost',
  maxSockets: 100,
  keepAlive: true,
  maxFreeSockets: 10,
  freeSocketTimeout: 30000,
  timeout: 60000,
  keepAliveMsecs: 300000,
});

const onProxyRes = (proxyRes, req, res) => {
  let key = 'www-authenticate';
  proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');
};

const onProxyReq = (proxyReq, req, res) => {}

module.exports = {
  '/api/*': {
    host: '<HOST>',
    port: 443,
    path: '/api/*',
    target: "https://<HOST>",
    secure: false,
    logLevel: "debug",
    changeOrigin: true,
    agent: keepaliveAgentNTLM,
    onProxyRes,
  }
};

@mvpete

I think I found a solution to the infinite popups, I simply changed the maxSockets to 1. Probably not the best solution but it seems to work.

My Agent is set up this way:
return new Agent({
    maxSockets: 1, 
    keepAlive: true,
    maxFreeSockets: 10,
    keepAliveMsecs:100000,
    timeout: 600000,
    keepAliveTimeout: 90000   
  });
Hope that helps!

This solved the authentication popup issue for me, along with @mvpete 's explanation. The insidious part of this issue for me was that at first the keepaliveagent settings suggested by @chimurai worked, but as I added more API calls to my app, the login/authentication popup started displaying intermittently. After a few refreshes, it would stop popping up. I now understand that per @mvpete explanation there was probably only two or three sockets being used and once the api calls that were causing the login pop got routed through the one socket that had done the NTLM authentication, then the login dialog would stop showing.

I was having this problem of re-authentication, even after entering my credentials. It appeared stable at some points, and not at others. Anyways, I finally found a configuration for utilizing a proxy that is communicating with an API utilizing NTLM (that works for me). Since applying this, I have yet to have the constant re-auth issue. Just posting it here in the event it helps anyone else.

Note, this was for an Angular project, but I believe http-proxy-middleware is leveraged. Note, the onProxyReq can be removed. Also, I access the webserver @ https://localhost:4200, not https://127.0.0.1.
const { HttpsAgent } = require('agentkeepalive-ntlm');

const keepaliveAgentNTLM = new HttpsAgent({
  cookieName: 'localhost',
  maxSockets: 100,
  keepAlive: true,
  maxFreeSockets: 10,
  freeSocketTimeout: 30000,
  timeout: 60000,
  keepAliveMsecs: 300000,
});

const onProxyRes = (proxyRes, req, res) => {
  let key = 'www-authenticate';
  proxyRes.headers[key] = proxyRes.headers[key] && proxyRes.headers[key].split(',');
};

const onProxyReq = (proxyReq, req, res) => {}

module.exports = {
  '/api/*': {
    host: '<HOST>',
    port: 443,
    path: '/api/*',
    target: "https://<HOST>",
    secure: false,
    logLevel: "debug",
    changeOrigin: true,
    agent: keepaliveAgentNTLM,
    onProxyRes,
  }
};

I went and read about agentkeepalive-ntlm and it says:

Since NTLM works on the principal of the same user connecting over a authorized socket, we should reuse the same socket per URL for a user.

So it's essentially doing the same thing as setting maxSockets: 1. In my case, I only need to use http-proxy-middleware when developing locally. My API runs in Visual Studio and my frontend in VS Code. For me, just the regular keepaliveagent worked by setting the maxSockets to 1. agentkeepalive-ntlm seems to be more if you need this in production and you need to support multiple concurrent users, e.g. cloud environment and such.

Having followRedirects: true in the proxy config can also cause this error.

I'm still open to work on this with someone, I can help with the protocol side.

Navigation Menu

Repository navigation

Api behind Basic authentication and NTLM authentication #39

NTLM Authentication Scheme for HTTP

Keeping the connection alive

64 remaining items

Here is my working configuration with Vue-cli 3 / .NET WebAPI

Here is my working configuration with Vue-cli 3 / .NET WebAPI

Description of what the bug is

Settings of our application

The current behavior

The expected behavior

What we tried

UPDATE:

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Api behind Basic authentication and NTLM authentication #39

Description

Activity

chimurai commented on Nov 20, 2015

chimurai commented on Nov 20, 2015

zychj1 commented on Nov 25, 2015

chimurai commented on Nov 25, 2015

zychj1 commented on Nov 26, 2015

chimurai commented on Nov 26, 2015

NTLM Authentication Scheme for HTTP

Keeping the connection alive

chimurai commented on Dec 4, 2015

pierreconstantial commented on Apr 25, 2016

chimurai commented on Apr 25, 2016

EladBezalel commented on Nov 14, 2016

64 remaining items

DustinDSchultz commented on Jul 18, 2019

Aaron-Pool commented on Jul 25, 2019

sm-cdecker commented on Jul 30, 2019

mgoertz-dev commented on Feb 19, 2020

maa105 commented on Apr 16, 2020

sam-michael commented on Apr 29, 2020

babycasper123 commented on May 10, 2020

Here is my working configuration with Vue-cli 3 / .NET WebAPI

alexmnv commented on Mar 30, 2021

Here is my working configuration with Vue-cli 3 / .NET WebAPI

mvpete commented on Oct 14, 2021

NiceStepUp commented on Aug 31, 2022

Description of what the bug is

Settings of our application

The current behavior

The expected behavior

What we tried

UPDATE:

wolfie82 commented on Oct 20, 2022

adolfox commented on Jun 11, 2023

adolfox commented on Jun 11, 2023

dsebata commented on Apr 4, 2024

mvpete commented on Apr 4, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions