You can either: not grant Anonymous any privileges (Anonymous does not belong to any groups so it doesn't have any by default) specifically add a Restriction to the Administrator role for Anonymous (this actually means Anonymous is restricted from performing any tasks that an Administrator could do, which is all of them)

Thanks Tod! One of the downsides of moving to a beta-version of any product of course ;-). Looking forward to the next update. I'll try moving forward without the test, results are looking promising. Thanks!

Maybe you want to write an Extension for ProGet that is invoked whenever a apackage is pushed to a certain feed. Once triggered, you cando whatever you need to do in your extension.

Hi Matt, I would suggest to attach fiddler, and see what's going on. That XML you pasted is what a NuGet endpoint looks like; from there you can append /Packages to the URL, and see more of the exposed API.

ProGet is currently on-prem only, though you could install an instance in the cloud quite easily (a lot of people do that). We will likely have a SaaS/hosted version in middle of next year.

Based on the message, it would appear the registry is not pointing to ProGet, but is instead pointing to npmjs.org. I would do a wireshark or fiddler trace to see where it's actually going, and note what's being passed through.

That should work; but if not, I would make sure that the instance is actually named that (that's the default name), and that the SQL Server is actually running. It's possible the service has stopped.

There is nothing in ProGet you can change at this time that would get around this. Maybe you could create another website that for example, redirects requests from http://repo.ingresso/nuget/ingresso-nuget to http://nuget.ingresso/ ? I'm not sure how well that would work though as it relies on the clients themselves following redirects. You also may have some luck with IIS URL Rewiting.

Unless something has changed, you cannot use Integrated Authentication with npm because the client doesn't support it: http://inedo.com/support/questions/2647 However, if you enable LDAP authentication in ProGet and then disable Integrated Authentication, you'll be able to use your Windows credentials. If it's the backslash that isn't supported, try the Active Directory provider, which supports the user@domain syntax.

Yes, we are in the investigation phase of adding this feed type. If it turns out it's as simple as sharing the functionality of the NuGet feed, it will be released earlier rather than later, but we do not have a scheduled date yet as to when it will be shipped.

The size and last modified/write date are used to determine if a file changed, but in pre-4.9 versions, the local time the server creating the artifact is used in the zip file (instead of UTC), which meant the deployed timestamp could be wrong. That said, it wouldn't cause a full redeploy... only an incorrect timezone. So, let us know if you see behavior like this (or can repro it with a smaller, less important deployment). It's possible the SSH library we're using handles returning dates differently, and there's an edge case we need to address.

Yes, that's just fine!

The connector authentication is for basic auth, if you're using integrate authentication then it may not be required (assuming that it's configured properly on the Windwos/domain side)

Status code 403 is an authentication problem; so most likely, the user or account that Git is pointing to has a password or permissions change.

Ah, I see -- everything is logged to that in the database, there are no additional files. The error log is primarily for diagnostic purposes, and sometimes errors are expected. That particular error, for example, it sounds like your server is trying to connect to Inedo.com to see the available extensions. It's OK if you can't do that, but, that's where it's logged.

Alex, different Workflows, of course! Sorry I should have thought of that. Thanks!

The Click Once Action is essentially a wrapper around mage.exe; you can see exactly how this is wrapping that utility in the source code: the source code, and what those options mean at msdn. The AppCodeBase is the deployment root of your application in IIS, generally "/", but it could be "/MyApp" or something as well. If you specify "CopyFiles" in the action, then the application files and manifest will be in whatever target directory you specify. If you do not specify a source and target directory, then the default/working directory will be used for both (which means the output will be exactly where the input was -- in the $CurrentDirectory).

The current (v4) execution engine does not support Array-type variables, so this would not be possible using that technique. But we will soon (couple weeks) be shipping v4.9, which will include a brand new execution engine, that will include Array/Vector variables, so you could do something like ... foreach $value in @MyVariableList { Transform-Config (...); }

Got it working. Thanks, that helps a lot!

These "URL scanners" all use the same, third-party reporting source, so they will all report the same false positives. We have no control over that obviously, and this only seems to affect certain URLS (not files or content at the url), and only for a couple days... which reaffirms that these URL scanners are fairly worthless, since a malicious file would just use a dynamic url. If you are concerned about the url scanner, then just use a different url to download the file --- https://s3.amazonaws.com/cdn.inedo.com/XXX instead of http:///cdn.inedo.com/XXX Even if Amazon's CDN servers were compromised , you can be rest assured that, if the installer you download is signed by Inedo, then it's the package we published. You can always manually install if you are you don't trust installers. WE would appreciate, however, if you report the false positive, as that's the only way these 3rd party reporting services will update their lists.