On IIS: npm adduser fails on server with a NotSupportedException: The given path's format is not supported.

[Guest]

We have a private NPM feed called NpmInternal on our ProGet server we use to push our NPM packages on our own 2012 R2 machine and our own IIS.

I am trying to configure a client machine to authenticate against ProGet so that npm install works correctly. ProGet was recently upgraded from 4.1 to 4.6.

As per the documentation, I run the following commands:

npm config set registry http://proget.private-server.com/npm/NpmInternal/
npm adduser

After entering username, password, and e-mail, all three registered and validated through the web GUI, the command fails spectacularly.

Using npm adduser --verbose, I get the following:

npm info it worked if it ends with ok
snip...
npm verb bad json <!--
npm verb bad json [NotSupportedException]: The given path&#39;s format is not supported.
npm verb bad json    at System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Boolean needFullPath)
npm verb bad json    at System.Security.Util.StringExpressionSet.CreateListFromExpressions(String[] str, Boolean needFullPath)
npm verb bad json    at System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess access, AccessControlActions control, String[] pathListOrig, Boolean checkForDuplicates, Boolean needFullPath, Boolean copyPathList)
npm verb bad json    at System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess access, String path)
npm verb bad json    at System.Web.InternalSecurityPermissions.PathDiscovery(String path)
npm verb bad json    at System.Web.HttpRequest.get_PhysicalPath()
npm verb bad json    at Inedo.Web.InedoHttpModule.MapHandlerAndBeginRequestAsync(HttpApplication app)
npm verb bad json    at Inedo.Web.InedoHttpModule.ProcessBegin(Object sender, EventArgs e, AsyncCallback cb, Object extraData)
npm verb bad json    at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

Now, that smells and quacks like a configuration error, but :

• All paths (as reported by /administration/advanced-settings) are correct
• The web GUI works as expected and does not report any error (I can access my target feed and all packages just fine through the GUI)
• /administration says There are no recent errors
• I was able to login on a different machine before the ProGet upgrade.

Update

Looking at HttpRequest.PhysicalPath-related errors, it seems the exception was thrown because there was a colon (:) in the URL (PUT http://proget.private-server.com/npm/NpmInternal/-/user/org.couchdb.user:my.username).

Adding the attribute relaxedUrlToFileSystemMapping="true" to ProGet's Web.config fixes the issue. It opens up its own share of potential security issues, too, so I cannot recommend it.

Was it on purpose, or did I miss a configuration step ?

Versions: npm@4.0.3, node@v7.2.1, Windows Server 2012R2.

Thanks.

Cheers,

Product: ProGet
Version: 4.6.1

[Guest]

Thanks for the detailed investigation into this. Given the format of some of the URLs that npm uses, there is really no avoiding adding this attribute that I'm aware of. We'll do a more detailed analysis of the security implications before we have any firm recommendations, but the ProGet web application doesn't actually use static file handling at all, so the risk for this attribute should be minimal.

That said, are you running under Integrated or Classic mode for your ProGet AppPool? It works under both, but we recently switched the default to Integrated, so it's possible this behavior has changed due to that.

[Guest]

Hi Dean,

My ProGet AppPool is running under classic mode. Looks like the upgrade didn't change that.

I tried switching to Integrated, but found the same symptoms and the same results.

Cheers,

[Guest]

It looks like there was a regression in 4.6.0 that is causing this change in behavior. We'll have it fixed in ProGet 4.6.3, which will should be released by tomorrow at the latest.