We have a site built in EPiServer and is running on www.mysite.com
Now we have built a small .NET microsite that isn’t part of the EPiServer project that we would like to run as a IIS Virtual Directory www.mysite.com/microsite
At the moment we are seeing 404 being returned for all of the assets on the microsite so www.mysite.com/microsite/assets/js/myjs.js or www.mysite.com/microsite/assets/img/myimg.jpg
The home page of the microsite is served, but with missing assets.Is there a way I can configure the main EPiServer project to ignore all of the requests to my microsites folder structure.
After a while battling this issue we have now got a repeatable solution.
In the parent application (EPiServer solution) we need to add the following location element in the web.config
<location path="MY-IIS-APPLICATION-NAME">
<system.webServer>
<handlers>
<clear />
<add name="wildcard" path="*" verb="*" type="System.Web.StaticFileHandler" />
</handlers>
</system.webServer>
</location>
Then, in the same web.config we wrap the <system.web> and <system.webserver> sections with this element <location path="." inheritInChildApplications="false">
Finally we need to alter the web.config in our IIS-Application to unload the EPiServer handlers and libraries.
So, in the <system.web> section we added these elements
<httpModules>
<clear />
</httpModules>
<httpHandlers>
<clear />
</httpHandlers>
then within the <system.webserver> we make these changes/removals
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
</handlers>
<modules>
<remove name="InitializationModule" />
<remove name="FirstBeginRequestModule" />
<remove name="Initializer" />
<remove name="WorkflowRuntime" />
<remove name="UrlRewriteModule" />
<remove name="ShellRoutingModule" />
<remove name="ContainerDisposal" />
<remove name="PropertyInjection" />
<remove name="AttributedInjection" />
</modules>
There is every chance that this isn't the solution, but in the last few days we have rolled this out to 6 different projects and it has had the desired effect each time.
Related
URIs with a trailing period seems to be problematic for IIS. I have configured IIS to include a wide range of characters for my ASP.NET MVC 5 app, including periods and other characters (&, %, +, - etc.). Only in cases of period as the last character does IIS give a 404 without ever hitting the controller.
I've added some commonly suggested points of configuration to allow the unusual characters. I have a large set of data with little control over the URIs permissible. The data is all served by the controller and does not map to a file system.
<location path="data">
<system.web>
<httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" relaxedUrlToFileSystemMapping="true"/>
<httpHandlers>
<add path="*" type="System.Web.Handlers.TransferRequestHandler" verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" />
</httpHandlers>
</system.web>
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true" />
</security>
<modules runAllManagedModulesForAllRequests="true" />
<validation validateIntegratedModeConfiguration="false" />
<handlers>
<add name="DataHandler" path="*" verb="GET" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
</location>
What am I missing?
I have created a .Net project 4.6 using web api.
just for simplicity purpose, I created default.htm in the parent directory. I publish my project to localhost, and set up the default document to default.htm as per the screenshot:
published web.config:
<system.web>
<authentication mode="None" />
<compilation targetFramework="4.6" />
<httpRuntime targetFramework="4.5.2" />
<httpModules>
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" />
</httpModules>
<customErrors mode="Off" />
</system.web>
<system.webServer>
<modules>
<remove name="FormsAuthentication" />
<remove name="ApplicationInsightsWebTracking" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" preCondition="managedHandler" />
</modules>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
However, whenever I navigate to http://localhost/, it always returns 404 as per the screenshot below: Can someone please help? Thanks
I am using port 80:
All published Web Site in IIS need to have a port like this:
1.Assuming you are using the port of 8462.
2.Try to navigate this url = localhost:8462
Make sure your asp.net has been registered to your IIS like this aspnet_regiis -i
Good Luck!
Hi I'm trying to run dotless on my local .net4 web site
My web config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
</configSections>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<httpHandlers><add path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler, dotless.Core" /></httpHandlers></system.web>
<dotless minifyCss="false" cache="true" web="false" />
<system.webServer>
<handlers>
<add name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
</handlers>
</system.webServer>
</configuration>
Here is the error I get
HTTP Error 500.23 - Internal Server Error
An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.
Most likely causes:
This application defines configuration in the system.web/httpHandlers section.
Can you please help?
adding <validation validateIntegratedModeConfiguration="false"/> worked
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
</configSections>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<httpHandlers>
<add path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler, dotless.Core" />
</httpHandlers>
</system.web>
<dotless minifyCss="false" cache="true" web="false" />
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
<add name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
</handlers>
</system.webServer>
</configuration>
<validation validateIntegratedModeConfiguration="false"/> tells IIS to ignore configuration issues. One such issue seems to be the fact that dotless automatically adds a handler to system.web and system.webServer. The former section is used by the classic application pool mode, whereas the latter by the new integrated application pool mode. Since I am using the integrated mode, removing the handler in system.web helped just as well.
I had to add <validation validateIntegratedModeConfiguration="false"/> to my webserver section and I also had to move the configSections to be the first element in my Configuration.
<configuration>
<configSections>
<section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
We will add a small piece of code into web.config file. open web.config from your IIS root or change the setting in Visual Studio web.config and publish again.
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
</system.webServer>
When using the April 2013 AjaxControlToolkit I receive the error:
0x800a139e - JavaScript runtime error: error raising upload complete event and start new upload
When trying to upload a file using the AjaxFileUpload control.
Make sure the following stuff should be present in web.config.
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" maxRequestLength="42949672" />
<httpHandlers>
<add verb="*" path="AjaxFileUploadHandler.axd" type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit"/>
</httpHandlers>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
<add name="AjaxFileUploadHandler" verb="*" path="AjaxFileUploadHandler.axd" type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit"/>
</handlers>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="4294967295"/>
</requestFiltering>
</security>
</system.webServer>
</configuration>
To resolve the error you need to add this
<httpHandlers>
<add verb="*" path="AjaxFileUploadHandler.axd" type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit"/>
</httpHandlers>
in your
<system.web>
section of your web.config
If your app pool is set to classic then this happens unless you use precondition=”integratedMode” added to httphandler for system.webserver
<add name="AjaxFileUploadHandler" verb="*" path="AjaxFileUploadHandler.axd" type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit" preCondition="integratedMode"/>
Had the same issue after switching to 4.5. The suggested solution didn't worked until I added full assemply name:
<httpHandlers>
<add verb="*" path="AjaxFileUploadHandler.axd" type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit, Version=4.5.7.725, Culture=neutral, PublicKeyToken=28F01B0E84B6D53E" />
</httpHandlers>
Turns out, if you have the 3.5 version in the "old" gac, and 4.5 in the new Microsoft.net/assembly gac, your webapp (IIS?) will not choose the right one!?
Since my application uses forms authentication, I added this to my web.config in order to put the ajaxfileupload to work:
<location path="AjaxFileUploadHandler.axd">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
If anyone still facing the issue even after the changes said by #sridharnetha try to include the below lines.
Important to add UseAbsoluteHandlerPath ="false"
<ajax:AjaxFileUpload ID="AjaxFileUpload11" runat="server"
MaximumNumberOfFiles="3" AllowedFileTypes="txt,xls,xlsx,doc,docx,pdf"
Width="400px" UseAbsoluteHandlerPath ="false"
OnUploadComplete="OnUploadComplete"
OnClientUploadStart="UploadStart"
OnClientUploadCompleteAll="UploadComplete"
ClearFileListAfterUpload="true"
OnClientUploadError="UploadError"/>
In Web.config
<httpHandlers>
<add verb="*" path="http://localhost/AjaxFileUploadHandler.axd"
type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit" />
</httpHandlers>
I have a website running on a IIS 7.5 server with ASP.NET 4.0 on a shared host, but in full trust.
The site is a basic "file browser" that allows the visitors to login and have a list of files available to them displayed, and, obviously, download the files. The static files (mostly pdf files) are located in a sub folder on the site called data, e.g. http://example.com/data/...
The site uses ASP.NET form authentication.
My question is: How do I get the ASP.NET engine to handle the requests for the static files in the data folder, so that request for files are authenticated by ASP.NET, and users are not able to deep link to a file and grab files they are not allowed to have?
If you application pool is running in Integrated mode then you can do the following.
Add the following to your top level web.config.
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Now you can use the standard ASP.NET permissions in your web.config to force forms authentication for all files in the directory.
<system.web>
<authorization>
<deny users="?" />
</authorization>
<authentication mode="Forms" />
</system.web>
I had the same problem with getting roles to authenticate. Through trial and error I finally got it to work with a small edit to #Joel Cunningham's code:
<modules runAllManagedModulesForAllRequests="true" >
I used these two sites as references: http://forums.iis.net/t/1177964.aspx and http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis-integrated-pipeline/
This is an old thread, but I happened on it and ran into the same problem as Egil. Here is the version of Joel's fix that includes roles:
<modules runAllManagedModulesForAllRequests="false">
<remove name="FormsAuthenticationModule" />
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
Addendum:
As #eych noted the accepted answer also blocks access to the ~/Content folder (or wherever you have your CSS), and ~/Scripts, and so on.
If you want to allow exceptions -- i.e. allow certain files/folders to be accessible by unauthenticated users -- you can do that by means of the location element. Add the following to web.config:
<location path="Content">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Update:
An alternative solution is to is to leave access on by default -- which will allow access to your CSS / JavaScript / etc. -- and apply the "lock" (only) to the folder where the static content is stored:
<location path="data">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
Caveat: in our case (an MVC site) we needed to decorate all our controller actions (except login) with [AuthorizeAttribute]. Which is a good idea anyway, but had previously not been necessary (because previously any unauthorized request was redirected to the login page).
I wanted to know why it would be required to re-add modules (with default options) that are added by default for the Integrated Pipeline, so I dug a little deeper.
You need to remove and re-add the modules because, by default, the modules aren't added with the default options. They have a precondition added for backwards compatibility to run only for content handled by a registered ASP.NET handler (e.g., .aspx pages).
The default looks like this:
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
preCondition="managedHandler" />
By removing the modules and re-adding them without a precondition, those individual modules run for every request (including your static content). It is more granular than enabling runAllManagedModulesForAllRequests.
You can read about it in a couple articles from when the Integrated Pipeline was introduced with IIS 7:
ASP.NET Integration with IIS 7
How to Take Advantage of the IIS 7.0 Integrated Pipeline
Note that there is a typo or the module name in the second article (and #John's answer) was changed from FormsAuthenticationModule to FormsAuthentication at some point.
The set of working modules in IIS 7.5 thru 8.5 looks like this for me:
<system.webServer>
<modules>
<!-- Re-add auth modules (in their original order) to run for all static and dynamic requests -->
<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
</modules>
</system.webServer>
If you application pool is running in Classic mode, you can do the following. You will have to repeat these steps for each file extension you'd like to handle, but I'm using .html here.
First, add a page build provider to the Web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<compilation>
<buildProviders>
<add type="System.Web.Compilation.PageBuildProvider" extension=".html"/>
</buildProviders>
</compilation>
</system.web>
</configuration>
Then add a page handler factory:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpHandlers>
<add type="System.Web.UI.PageHandlerFactory" path="*.html" verb="*"/>
</httpHandlers>
</system.web>
</configuration>
Then add a page handler:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" name="HtmlHandler-Classic-32" />
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" path="*.html" verb="GET,HEAD,POST,DEBUG" name="HtmlHandler-Classic-64"/>
</handlers>
</system.webServer>
</configuration>
This worked for me. (Credit: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages.)