We have an application which is developed using MVC3 and .Net framework 4.0. To prevent HTTP Verb Tampering, we have included below code in application's web.config file. In local machine given fix was working as expected and returns 401 unauthorized code.
<authorization>
<allow verbs="GET" users="*" />
<allow verbs="POST" users="*" />
<deny verbs="*" />
</authorization>
When we deployed the same code, test result returns 202 OK. So the fix is not working. Is there any way around that we can fix this issue?
Are you are working with the "Play" button on Visual Studio? Is this using a IIS Express or are you really "deploying" that to an IIS WebAPP on your local machine?
I usually do not use the "Play" button when I am developing for IIS, specially when I am developing for a specif IIS Server. When that happens, I try to have the same IIS Server configuration on my machine and create a WebApp pointing to my Dev folder to test it.
If you are having trouble to config your web.config, I would use the IIS visual tools, check the modifications made on the web.config and commit that.
Please note that there are some differences in the configuration in the ASP.NET side and on the IIS side:
Please check this website:
https://learn.microsoft.com/en-us/iis/manage/configuring-security/understanding-iis-url-authorization
And refer to these notes:
Differences Between ASP.NET URL Authorization and IIS URL Authorization
There are small but important differences between ASP.NET UrlAuthorization and IIS URL Authorization.
ASP.NET Url Authorization is installed when you install ASP.NET on top of IIS.
This refers to IIS 7.0
Even though several configurations are compatible between one IIS to another, some specific changes might apply.
Related
I migrate an dotnet framework web api application from vs 2010 to 2019.
I want to use IIS express for developpement mode debug.
My application is built with a api back in dotnet framework 4.5 using xml and not json and a front in dotnet winform.
sorry for the french messages.
thanks a lot for your suggest.
I've been stuck with this for a week
Vincent
I tried to change the web.config, the applicationhost.config (in the user iis express directory and the .VS\config directory.
add modules to IIS manager
Try removing this line from your web.config,
<identity impersonate="true"/>
Or,
as Described in here;
Your application's Web.config file specifies "identity
impersonate='true'".
In IIS 7 Integrated mode, client impersonation is not available in
some early request processing stages. Therefore, IIS will generate the
migration error message. If your ASP.NET Web application impersonates
client credentials (most common with intranet scenarios), you may want
to set the validateIntegratedModeConfiguration attribute to false.
Add this section to your config to overcome this issue,
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
thanks for your help
I have tried
validateIntegratedModeConfiguration="false"
and it worked only when I deleted the lines created in the applicationhost.config (but it's not a solution)
we finally found: the problem was that I modified the .csproj file; but the file used for the user configuration is the .csproj.user.
It is modified with the "property" tab of VS.
I had seen it in a post for an mvc web application, since we are using an api, I thought it was different because it is an api.....
My colleague showed me the options in the panel... and now it works!!!!
[]You have to modify in properties :
anonymous authentication : disable
windows authentication : enable
pipiline mode : classic
and that's all
Make sure all the following .NET modules are installed.
.NET SDK 6.0.100
.NET Runtime 6.0.0
.NET hosting 6.0.0
note that the above are the current versions the versions may differ.
also change the version of .config files by running as Administrator whether you open the .json on Notepad or your IDE.
make sure your Internet Information Services is up to date and have selected all features on IIS
I have a website hosted on nodejs, using http-proxy-middleware where I proxy all the api calls to an ASP.NET API.
I have the ASP.NET api deployed on a remote IIS server (not on my computer but in the domain) with windows authentication on with NTLM only and I have this in the web.config:
<system.web>
<compilation debug="true" targetFramework="4.5.2" />
<httpRuntime targetFramework="4.5.2" />
<authentication mode="Windows" />
</system.web>
When I set up my website on a local IIS server (on my computer) and set its authentication to anonymous this works correctly, no login popups.
Calling the api from postman with NTLM authentication also works perfectly.
But when I deploy the website to the remote IIS server I can open the site without problems but when the site queries the API I get a login popup that does not accept my credentials (mydomain\myusername), it will instead show the popup again and again in chrome but stop after 3 tries in IE and return a 401 unauthorized error.
Because this works locally I'm thinking the problem must be somewhere with the IIS server but I cannot figure out what it is.
There was a problem with the IIS server, when trying to fix the problem I often switched between anonymous and windows authentication but the changes didn't work unless i restarted the IIS by writing iisreset /noforce in the command console afterwards
By doing this on the remote IIS it worked like it did on my local IIS.
I am doing URL to image conversion using HiQPDF. The conversion works on localhost. It also works on AWS when the hosted application is opened from browser. It doesn't work on other environments like my personal computer and another machine where I am logging in using VPN, on any browser. ConvertURLToImage(url) throws this error -
"Navigation error. The remote server closed the connection before the entire reply was received and processed."
I don't think it has got to do with any IIS settings otherwise it wouldn't have worked on AWS.
I have added the following in Web.Config for access to my URL -
<location path="export/execReportDashlets">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
I just ran into the same "Navigation error..." message while trying to generate a PDF. We are using version 8.10 of the HiQPdf software, which is working fine for some connections and has started failing for others. After digging into the issue I believe our problems are related to SSL/TLS connections. On our newer servers we don't allow anything below TLS 1.1, if we relax those rules the connections are successful. I upgraded HiQPdf to version 10.17 and ran some tests. Connections using the updated component are working fine with our newer server configuration. There doesn't appear to be any mention of updates having to do with secure connections on their site though and both versions are using the same runtime version. I have a support request in with them to confirm, but I think upgrading will fix the issue for us.
Maybe relevant, maybe not, depends on the request.
Update:
HiQPdf support got back to me with the following:
The latest version should work with TLS 1.1 and 1.2. You can try the latest version in demo mode if you don’t set a serial number.
In my project, I use windows authentication for auditing purposes (rather than logging in), so I know who has made certain changes. The variable used to access the usernames is User.Identity.Name and I have also made sure to set up my web.config file correctly:
<system.web>
<authentication mode="Windows" />
</system.web>
This all worked fine, but I have recently published my project to a live server and for some reason it has stopped seeing the usernames (it now logs a blank string instead), even though it worked on my local machine. Any idea what I may have missed to make this work on a live server? It still works with no problems on my local machine.
It works on localhost, but finds no default document on the webserver and complains about directory browsing being disabled. IIS7 on both, and both websites/app pools seem to be configured identically.
I've used the web api template in VS2012, which doesn't actually have any views. It only has an Index controller action in the HomeController.
Any ideas on why this could produce different behavior in the two environments?
So this addition to my web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<system.webServer>
fixed the problem. It seems to be required in the web.config for IIS7 on Windows 2008 Server, but not for IIS7 on Windows 7.
I had a user trying to publish a MVC4 application on IIS7 getting this error, it turned out it was because the user had set the application pool to use .Net 2 instead of .Net 4. Instead of getting an error indicating this though they received the above error, and it was only when we added the above module the real issue was uncovered.