I have an IIS6 running on Windows Server 2003 (x86) and have written a custom handler (Not a handler for 404 errors).
When I try to access the handler by opening in a browser http://localhost/Priority1.Sync/Transfer.p1s, I get error 404 (404 0 in log file). Other pages in the web application work, e.g. http://localhost/priority1.sync/syncservice.asmx
The handler works fine on my IIS7 dev machine.
web.config is setup as follows:
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="GET,HEAD" path="ScriptResource.axd" validate="false" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add verb="*" path="*.p1s" type="MCS.Priority1.Sync.WebServices.TransferHandler, SyncService" />
</httpHandlers>
I have set an application extension for "*.p1s" (Default Web Site>Properties>Home Directory>Configuration>Mappings>Add).
Am I missing something else?
Thanks,
Andy
Do you have the "Verify that file exists" option in your custom handler IIS configuration checked or not?
IIS6 expects a physical file to exist by default. If there isn't one, it won't pass the request on to your handler at all. You need to disable this check, so it will send the request to your handler as expected.
IIS6 and IIS7 are fundamentally different beasts. IIS7's managed pipeline means every request hits your registered handlers, in IIS6 only things mapped to ASPNET_ISAPI.DLL (typically *.aspx and *.ashx and other default ASP.NET extensions) get processed.
You can make your IIS7 dev box behave this way by using the "classic" pipeline for your development app pool for this project.
Another trick to making it work how you expect is to map 404 errors to an ASP.NET page and then you can at least get into your handler.
In all honesty I would look towards upgrading production to IIS7 as it is so vastly more capable it isn't even funny.
If you are registering handlers for IIS 6 then do remember they should be placed in the
<httpHandlers> element of <system.web> section of the web.config not the <system.webServer> section that IIS7 uses.
Related
We are running an ASP.NET 4.6 application with ADFS 2.0. The configuration of the web.config ADFS part was created via FedUtil.exe.
We now have the problem that a second instance of the web application still thinks that the user is not authenticated.
auth on server 1 works only on server 1
auth on server 2 works only on server 2
but..
auth on server 1 cannot be recognized on server 2 and vise versa
In our scenario only a sticky session would work in a load balanced environment. I think it is because of the SessionModule which is required:
<modules>
<add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" />
<add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" />
</modules>
Am I right that the SessionModule stores any data of the auth* into a session, so a shared session would not be possible and we are forced to use sticky sessions?
Would IdentityServer3 or IdentityServer4 solve this issue?
It seems to be that the Microsoft.Identity does not provide SAML Tokens without Sticky Sessions: https://leastprivilege.com/2012/07/12/machinekey-based-session-protection-for-wif/
I'm facing a weird issue with the WIF ClaimsAuthenticationManager. I have registered the custom implementatin of the ClaimsAuthenticationManager in the web.config file:
<identityConfiguration>
<claimsAuthenticationManager type="<namespace>.CustomClaimsTransformer,<assembly>" />
<claimsAuthorizationManager type="<namespace>.CustomAuthorisationManager,<assembly>" />
....
When i run the application in the IISExpress the authenticate method of the ClaimsAuthenticationManager gets invoked. However, it's not being invoked ever since i deployed the application on IIS 7.5.
Is there any configuration that needs to be done?
In the system.webserver part of your web.config do you have the ClaimsAuthorizationModule set,
eg
<add name="ClaimsAuthorizationModule" type="Microsoft.IdentityModel.Web.ClaimsAuthorizationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
For .NET 4.5 you have to add this:
<add name="ClaimsAuthorizationModule" type="System.IdentityModel.Services.ClaimsAuthorizationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
ClaimsAuthenticationManager is not invoked automatically. One needs a plumbing code for that unless they are using WS-Federation.
You can do it in an PostAuthenticateRequest event handler for the HttpApplication.
A good example is located in the http://github.com/thinktecture/Thinktecture.IdentityModel.45 project. Search for ClaimsAuthenticationHttpModule.cs which invokes it.
I have a web service file in my project having a web method which is used for AutoCompleteExtender and which works fine when I debug it from VS.
But when I publish and host it on IIS, it's not working properly.
However, I tested the webservice method directly by typing the URL and it gave the desired output.
Is their a special setting needs to be done in IIS to make it working or any property of AutoCompleteExtender need to be set?
I had this issue as I moved a site from cassini to IIS7.5. After a lot of digging had to add the follwoing to the web.config in the system.webServer section. Hope it helps.
<modules runAllManagedModulesForAllRequests="true">
<remove name="ScriptModule" />
<add name="ScriptModule" preCondition="managedHandler" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</modules>
<handlers>
<remove name="ScriptHandlerFactory"/>
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</handlers>
After a upgrade from ASP.NET 3.5 to 4.0 I have the same problem and can't get the extender to work. From firefox and firebug I recive a 500 Internal Server Error with the message
System.InvalidOperationException: Request format is invalid: application/json; charset=utf-8.
at System.Web.Services.Protocols.HttpServerProtocol.ReadParameters()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
I have tested with the web.config settings suggested by http://msdn.microsoft.com/en-us/library/bb763183.aspx but recive configuration errors.
Try changing the order of the handlers (remove then add). In this example I have removed all but the AJAX/script handler.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<remove name="WebServiceHandlerFactory-ISAPI-2.0"/>
<remove name="WebServiceHandlerFactory-ISAPI-2.0-64"/>
<remove name="WebServiceHandlerFactory-ISAPI-4.0_32bit"/>
<remove name="WebServiceHandlerFactory-ISAPI-4.0_64bit"/>
<!--<add name="WebServiceHandlerFactory-Integrated-4.0" ...</handlers>
Its not the problem of IIS or ath. Its a bug actually (I think). In your function in webservice to return the string array please check the parameter names or arguments to the function.
The name of the string parameter must be prefixText and that of int field should be count.
And there must be these two parameters for your functions in the webservice.
like this
[WebMethod]
public string[] getCountry(string prefixText, int count)
{
......
....
return ...
}
I was facing the same problem. AutoCompleteExtender was not working after hosting in IIS 7 Windows Server 2008 R2.
By changing the "Managed Pipeline Mode" of Application Pool from "integrated" to "Classic" worked for me.
This setting can be taken by selecting the application pool -> select Basic setting.
Thank you.
Try...this
go to start>run>inetmgr>
In the connections sidepane..select application pools
select the application pool that u hav assigned when deployed that project into iis(to check that go to sites>in connections pane...and right click on website that u have deployed and select manage website >advanced settings then at the top u wil able to see application pool)
then comeback and select that particular application pool in application pools in connections pane
right click on that particular application pool and select advanced settings..find out process model in that and select identity and browse through it and goto built in account and select local system.......then click ok...and get out of it...
I think it will work..it worked for me.....
I have a reportviewer control that works fine locally, but when deployed to the IIS 7 webserver, it just returns a blank page (or XML error in Firefox).
I thought it was permission related but I've given everyone permission as a Hail Mary and still I get a blank report with typically sparse MS error handling to help me track down the issue.
Has anyone else run into this?
Using IIS 7 and ReportViewer 9.0
If your using IIS 6 for development and IIS 7 for deployment. IIS7 it might be using integrated pipeline. In that case
<add verb="*" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
will not fire and nothing is rendered. Either you switch to classic pipeline or update your web.config. HttpHandler have a different section in web.config for intregrated pipeline.
http://msdn.microsoft.com/en-us/library/ms228090.aspx
I added the name attribute to the what Fahad posted and this worked great. Thanks! I can now use my MVC project with a ReportViewerControl on a WebForms page. Exactly what I needed.
<add verb="*" name="ReportViewerWebControl" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
I have a weird issue that only seems to be affecting IE 7. The web site is a 3.5 c# asp.net website that utilizes ajax and the ajax control toolkit deployed to a win 2003 server. Everything appears to be correct in the web.config. In fact, everything works perfectly in IE6 and Firefox 3. It is only in IE7 that I get the dreaded sys is undefined error.
Also, the site appears to be working fine for IE7 on a different installation of the same code. That server is running win 2003 with very similar setups.
Since this appears to be a server issue, are there any kind of settings that would prevent ajax-enabled sites from displaying properly in IE7?
I know you said that everything appears to be correct in web.config, but still check it again on that server for this:
<add verb="GET,HEAD"
path="ScriptResource.axd"
type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
validate="false"/>
in the <httpHandlers> element.
If it is there, then in IE7 do View Source, and grab one of the ScriptResource.axd script reference URLs and just paste it into the browser and see what it comes back with.
Believe it or not, but emptying the temporary internet files solved the problem. I hate things like this!
I had this error when we moved to a new version of the AJAX Control Toolkit, and the new dll for that library didn't propagate out correctly when I rebuilt. So clearing the temp inet files is what I had to do also.
Are you using the "Combine Scripts" functionality of the AJAX Toolkit Script Manager? It's known to cause problems with some browsers/proxies, leading to the very error you're describing. I think it's enabled by default in 3.5, so you might want to look at shutting it off and seeing if your problems persist.
Are you sure that it is only IE7? Maybe other browsers are supressing the error. Firebug on Firefox might bring this to the surface.
The two times I have seen something like this were
a) using jQuery in the same project as ASP.NET Ajax, here jQuery's noConflict method helped out
b) Check the position of the ScriptManager on your page, make sure that it isn't being included in a Content Page but referenced above in a Master Page or something like that
Hope this helps
Try placing your javascript code below <asp:ToolkitScriptManager>
None of the suggestion worked for me, but when added the following under <system.web>, it worked!
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="false"/>
</httpHandlers>
<httpModules>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</httpModules>