Good day all
I'm completely stumped. I am developing an MVC App using MS VSExpress 2013 for Web, and am at the point where I need to add Windows Authentication. Creating a default MVC App using the Wizard and selecting Windows Authentication, it appears to work fine. Lets call the default App App1, my developed App App2.
Monitoring the Context.User object within Watch for both Apps:
App1 returns:
User {System.Security.Principal.WindowsPrincipal}
System.Security.Principal.WindowsIdentity
AuthenticationType "Negotiate" string
IsAuthenticated true bool
Name "MyDomain\\Andrew" string
When using the developed app, the result is as follows: Please note, the returned object is different (App1 = System.Security.Principle.WindowsPrinciple, App2 = System.Web.Security.RolePrinciple.
User {System.Web.Security.RolePrincipal}
Identity {System.Security.Principal.GenericIdentity}
AuthenticationType "" string
IsAuthenticated false bool
Name "" string
HttpContext.Current.Request.LogonUserIdentity.Name "MyDomain\\Andrew"
When switching the developed app Development Server properties to Windows Authentication = Enabled, Anonymous Authentication = Disabled, the result is an immediate:
Server Error in "/" Application.
Resource cannot be found.
Http 404...
Requested URL:/Account/Login
I've checked and compared:
Web.config files and IISExpress\config\applicationhost.config settings for both applications.
My limited knowledge (based on reading all the questions on SO I could find), I'm guessing App2 thinks it is using Forms Authentication, not Windows Authentication. App2 is getting the user information through the
HttpContext.Current.Request.LogonUserIdentity.Name object (found this on SO).
I've added:
<add key="autoFormsAuthentication" value="false" />
to Web.config ... no joy.
Anyone have any idea why the two apps are returning different user objects, and where this can be corrected? Why does App2 not get IsAuthenticated=true from the same IISExpress server as App1?
Thanks
http://www.itorian.com/2013/05/windows-authentication-in-mvc4-with-iis.html
For some strange reason (EDIT Here is the reason-> ASP.NET MVC3 and Windows Auth on IIS keeps redirecting to /Account/Login /EDIT , the wizard generated app1 did not require these two lines within Web.config
<add key="autoFormsAuthentication" value="false" />
<add key="enableSimpleMembership" value="false"/>
After adding the 2nd line, the Context User object returned changed from
System.Security.Principal.GenericIdentity
to
System.Security.Principal.WindowsPrincipal
and all is well.
Also ensure your IISExpress server config file applicationhost.config (within the IISExpress installation folder) contains correct entries as required:
Global Entry:
<windowsAuthentication enabled="true">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
Related
The issue I have is we currently are using IdentityServer as our SSO authentication for our corporate applications. However, the bulk of our applications are under the same Site ID in IIS 7.5. When navigating to more than 5 of these applications under the same Site ID, you end up getting a 400 error, request header too long. The reason being each application has its own cookie, so the request header is passing around 5+ cookies with token information and the becoming too large.
My question is, are you able to prevent the sharing of cookies between applications under the same Site ID in IIS 7.5?
We also have IdentityServer for SSO and internal applications hosted on the same machine on IIS.
And I faced with the same problem too.
Here is a solution:
1) You need to solve Owin/Katana middleware problem to avoid nonce overfloating. Here you can find the code for that fix
2) You have to stop sharing cookies.
So if your base address for applications is "mysite.com".
And you have a lot of different applications like this:
Good App: mysite.com/good_app/
Best App: mysite.com/best_app/
Super App: mysite.com/super_app/
Use CookiePath for each application on an application's side and it will limit cookies (and look here too).
Use the code like this (for "Good App"):
var cookieOptions = new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
CookieName = "GoodAppCookies",
// Cookie Path same as application name on IIS
CookiePath = "/good_app
};
Hope it'll help.
Few things that you can try. Make the following changes at the server level.
Highlight the server name in IIS, select "configuration editor", select "system.web" and "httpRuntime" and change "maxRequestLength" to "1048576".
You can also edit the "applicationHost.config" file in the following way- C:\Windows\System32\inetsrv\Config
<configuration>
<system.web>
<httpRuntime maxRequestLength="1048576" />
</system.web>
</configuration>
Edit "Request Filtering" settings at server level on IIS and set "maxAllowedContentLength" to "1073741824"
You can also edit the root web.config file in the following manner - C:\Windows\Microsoft.NET\Framework64*\v4.0.30319*\Config
*Folder is based on your application. if its a 32 bit application, navigate to "Framework" folder. If its a .net 2.0 application, navigate to v2.0.50727.
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
First of all - I want to say that I have not tried this myself, so I can't assure that it is a solution, but I'm trying to help.
The problem with the cookies originates from the Microsoft OWIN/Katana and the way they are encrypting them. They become enormous, but this has nothing to do with Identity Server. However here and here there are good discussion around this.
The main thing to try first is in the Startup.cs of the IdentityServer project, in the IdentityServerOptions.AuthenticationOptions there is a property SignInMessageThreshold which defaults to 5. Try setting it to something lower, this will keep your header smaller (which may cause round trips to identity server when an app doesn't have its message in the cookies, but this will not force the user to re-login).
Another thing, that we achieved in one of out projects, is to create a DataBase backed cookie session handler. In your clients, where you use
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
CookieName = cookieName,
});
There is also a property SessionStore. You can have a custom implementation of the Microsoft.Owin.Security.Cookies.IAuthenticationSessionStore. In our case this reduced the cookie size to less than (or around) 300.
I followed this article to deploy my ASP.NET MVC Core 1.0 app to local IIS on my Windows 10 that is using IIS 10. The application deployed successfully and it opens the home page fine. I'm using Individual User Accounts Authentication. On the home page when I enter login/password and click Login button, I get the following error. I'm using the latest versions of ASP.NET Core and VS2015. I used VS2015 Publish wizard to publish the app. Everything is done on the same machine:
An error occurred while processing your request.
Development Mode
Swapping to Development environment will display more detailed information about the error that occurred.
Development environment should not be enabled in deployed applications, as it can result in sensitive information from exceptions being displayed to end users. For local debugging, development environment can be enabled by setting the ASPNETCORE_ENVIRONMENT environment variable to Development, and restarting the application.
First, check the value of ASPNETCORE_ENVIRONMENT variable. You will have to set this environment variable to "Production" (or other environment than Development)
Otherwise, you can update web.config like this-
<configuration>
<!--
Configure your application settings in appsettings.json. Learn more at http://go.microsoft.com/fwlink/?LinkId=786380
-->
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\Application.exe" arguments="" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>
</aspNetCore>
</system.webServer>
</configuration>
Refer this post for more details.
I wanted to run it in development environment, so I added following in web.config file, and it worked for me:
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
If you are developing using ASP.NET CORE. You can find this setting inside properties and then in launchSetting.json file.
"profiles": {
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Production"
},
"nativeDebugging": false
},
"Ecommerce": {
"commandName": "Project",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Production"
},
"applicationUrl": "https://localhost:5001;http://localhost:5000"
}
}
Change "ASPNETCORE_ENVIRONMENT": "Development" to "ASPNETCORE_ENVIRONMENT": "Production"
You can find the launchSetting.json file by expanding properties
I had the same problem (ASP.NET CORE 3.1) but changing "ASPNETCORE_ENVIRONMENT" did not helped.
Scouring through the web I found that in Startup.cs, Configure method, this code was hiding the real issue.
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
Then I deleted the If block and added Database error pages ( You might need to Install Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore from NuGet )
app.UseDatabserrorPages();
So your Startup.cs will look like this
app.UseDeveloperExceptionPage();
app.UseDatabaseErrorPage();
app.UseHttpsRedirection();
//Others will be Okay
Then you will see the real errors on the webpage. For me it was
Login failed for user IIS APPPOOL\DefaultAppPool
So I had to run a GRANT SCRIPT. I just had to run this script on my SQL Server
IF NOT EXISTS (SELECT name FROM sys.server_principals WHERE name = 'IIS APPPOOL\DefaultAppPool')
BEGIN
CREATE LOGIN [IIS APPPOOL\DefaultAppPool]
FROM WINDOWS WITH DEFAULT_DATABASE=[master],
DEFAULT_LANGUAGE=[us_english]
END
GO
CREATE USER [WebDatabaseUser]
FOR LOGIN [IIS APPPOOL\DefaultAppPool]
GO
EXEC sp_addrolemember 'db_owner', 'WebDatabaseUser'
GO
You can see this link : https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/visual-studio-web-deployment/deploying-to-iis
And my problem was solved. Hope this helps somebody.
There is a runtime exception in code. in Production mode it can not be show. so that it show "Development environment should not be enabled in deployed applications, as it can result in sensitive information from exceptions being displayed to end users"
in web.config file you will find
<aspNetCore processPath="dotnet" arguments=".\PortfolioApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
replace it with
<aspNetCore processPath=".\Application.exe" arguments="" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
</aspNetCore>
now you run app in browser. It will show actual error message. Now it's time to fix the runtime exception.
I just replaced this:
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseMigrationsEndPoint();
}
else
{
app.UseExceptionHandler("/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
with this:
app.UseDeveloperExceptionPage();
app.UseMigrationsEndPoint();
When your connection string is not correct, you get this error. When I correct my connection string it worked fine.
Eg: for correct azure db connection string
Server={Server Name};Initial Catalog={Database Name};Persist Security Info=False;User ID={DB User Name};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
For me, it was a matter of adding the EnvironmentName property to the pubxml.
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/visual-studio-publish-profiles?view=aspnetcore-5.0
First, this error occurs where you publish a web site that raises errors in the run-time. So check your code again in the pages that give this error.
Then, set the value of ASPNETCORE_ENVIRONMENT variable to Production (instead of Development), you should also check the layout page and change <environment"development"> to <environment"Production">.
Finally, publish your web site.
This is tested in VS2017
This might not be the case for everyone, however I was trying to deploy a "release" configuration to a server that had an environment variable of "uat". I set up a uat configuration to use with my deployment and the message no longer appeared when navigating to my site url. Long story short, just make sure your intended build configuration matches the destination server as others have alluded to above!
The only way I could get rid of the Development Mode message was to change appsettings.json context from
Integrated Security=True
to specifying
User Id=username;Password=password and making sure the user was a db_owner.
By default, in production, you will see this error page unless you create/customize your own. Depending on the project type, it can be in different places like Pages/Error.razor or as a controller action.
This error message is just a hard-coded text in the Error.cshtml file, not the actual error message, only the RequestID is dynamically generated, but not helpful. It only comes up when you publish it to a production web server, and if there is an error.
The template wizard adds an Error.cshtml and Error.cshtml.cs files to the Pages folder if the project is a Razor Pages while it only adds an Error.cshtml to the Views\Shared folder if the project is MVC. This file was there since ASP.NET Core 2.0, still unchanged.
Code in the Error.cshtml file as follows (ASP.NET Core Razor Pages project):
#page
#model ErrorModel
#{
ViewData["Title"] = "Error";
}
<h1 class="text-danger">Error.</h1>
<h2 class="text-danger">An error occurred while processing your request.</h2>
#if (Model.ShowRequestId)
{
<p>
<strong>Request ID:</strong> <code>#Model.RequestId</code>
</p>
<p>#Model.</p>
}
<h3>Development Mode</h3>
<p>
Swapping to the <strong>Development</strong> environment displays detailed
information about the error that occurred.
</p>
<p>
<strong>The Development environment shouldn't be enabled for deployed applications.</strong>
It can result in displaying sensitive information from exceptions to end users.
For local debugging, enable the <strong>Development</strong> environment by setting the <strong>ASPNETCORE_ENVIRONMENT</strong> environment variable to <strong>Development</strong>
and restarting the app.
</p>
In the MVC project, the code is the same except first 2 lines, it has only one line, replacing ErrorModel with ErrorViewModel:
#model ErrorViewModel
If there is an error this file will show if the environment is NOT the DEVELOPMENT, while it will show the actual error message in the development environment, based on the code in the Configure method in Startup.cs file. The code below shows for Razor Pages, for MVC only change is the path to the Error file app.UseExceptionHandler("/Home/Error");:
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseDatabaseErrorPage();
}
else
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
We do not need to change the above code.
So this Development Mode message will come up for any error pops from the application. If you want to show the proper error messages, More information can be found here in the doc.
To avoid confusion, change the original message as shown above, <h3> header and <p> to:
<h3>This is Production Mode </h3>
<p>Contact the developers of the app. If you are the developer swap to the
Development environment to see detailed information about the error that occurred.
</p>
Now if we take a look at the line with <aspNetCore in the Web.config file in your server:
<aspNetCore processPath=".\OurASPNETCoreApplication.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
That indicates that this is in production mode by default since it doesn't include the child <environmentVariables> node. Now to change the environment to development change that line to:
<aspNetCore processPath=".\OurASPNETCoreApplication.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" >
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
</aspNetCore>
and restart the web server. It will show the actual error message.
Most of the time it will be the database configuration errors.
Alternatively use a third-party logging provider, like Serilog to write logs into a text file.
This is an old thread. I didn't find the answer here.
But I found a solution and want to share it.
All worked perfectly on my computer. But when I publish to the web server and open the new page "MyLogin" I get the error. Solution that worked for me:
Delete the "bin" and "obj" folder in the current Project.
Remove all files/folders on the destination folder on the web server.
This is the default error page with generic error message.
I got this error after deploying the ASP.NET Core 3.1 MC published application on shared hosting. Default Home and Privacy pages were working as expected but when I tried to open a page that was fetching data from database the above error shown.
Error reason: In appsettings.json, I updated connection string Data Source=MyPC\MSSQLSERVER14 with Data Source=.\MSSQLSERVER2. I copied this data source ".\MSSQLSERVER2" from shared hosting connection string and pasted it in appsettings.json
Resolution: Changed data source ".\MSSQLSERVER2" to ".\\MSSQLSERVER2".
"ConnectionStrings": { "AppCon": "Data Source=.\\MSSQLSERVER2xxx;Initial Catalog=sqldb;Persist Security Info=True;User ID=sqluser;Password=********" }
I've got an Azure Web App using ELMAH to log unhandled exceptions.
When I first deployed it, the web.config had the full SMTP setup defined in it, and ELMAH emailed exceptions:
<system.net>
<mailSettings>
<smtp from="me#mydomain.com">
<network host="smtp.mailprovider.com"
port="123"
userName="myUserName"
password="p#ssw0rd" />
</stmp>
</mailSettings>
</system.net>
The username and password have since been removed from the web.config, and they're now stored as application settings, configured through the Azure Portal.
Most of the emails I send still work fine, as the email code can access these application settings and use them when instantiating the SmtpClient, e.g.:
var userName = WebConfigurationManager.AppSettings["smtp.userName"];
var password = WebConfigurationManager.AppSettings["smtp.password"];
var credentials = new NetworkCredential(userName, password);
using (var smtpClient = new SmtpClient { Credentials = credentials })
{
await smtpClient.SendMailAsync(mailMessage);
}
What's the best way to get ELMAH to use the credentials stored in the application settings?
Options I can see:
There is a page on the wiki explaining how to use ELMAH's ErrorTweetModule to do an HTTP form post with the error details to any URL. The controller receiving the post could then use the stored credentials to email the details on.
The WebBase has a link to an article suggesting you can send emails directly to the recipient's SMTP server without authentication, but it says this may not work if you have DomainKeys set up, which I do.
This answer links to an article about intercepting the Mailing event, to customise the message.
I ended up creating a custom version of Elmah's ErrorMailModule, derived from the standard one, but overriding the SendMail method, based on some advice from Atif Aziz in a discussion on Google Groups.
The only changes required were to create the new module, and switch the Web.Config to use the custom module instead of the standard one.
Module
using System;
using System.Net.Mail;
namespace Test
{
public class ErrorMailModule : Elmah.ErrorMailModule
{
protected override void SendMail(MailMessage mail)
{
if (mail == null) throw new ArgumentNullException(nameof(mail));
// do what you want with the mail
// (in my case this fires up the email service, which
// gets the credentials from the Azure settings)
}
}
}
Web Config Changes
All that's required is to change the two occurrences of Elmah.ErrorLogModule, Elmah to your own module, in this case Test.ErrorMailModule.
So, instead of this...
<system.web>
<httpModules>
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah" />
</httpModules>
</system.web>
<system.webServer>
<modules>
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah" preCondition="managedHandler" />
</modules>
</system.webServer>
...you should now have this:
<system.web>
<httpModules>
<add name="ErrorMail" type="Test.ErrorMailModule" />
</httpModules>
</system.web>
<system.webServer>
<modules>
<add name="ErrorMail" type="Test.ErrorMailModule" preCondition="managedHandler" />
</modules>
</system.webServer>
You will still need the errorMail section, as Elmah is still responsible for creating the email. Mine looks like this:
<elmah>
<errorMail from="user#domain.com" to="user#domain.com" subject="Custom Email Module"/>
</elmah>
Creating a HTTP request could work, but that should be the solution if everything else doesn't work IMO. Intercepting the Mailing event doesn't work, since you do not have access to the SmtpClient with the credentials in that event.
I've looked at different ways to update the SMTP settings from code. At first I though that I could just get a reference to the smtp section and update the properties, since they all have setter. But the code throw a configuration exception on runtime.
From what I can find, the only way to update the username and password in smtp section, is to read the web.config, update it and write the new version. Here's an example of writing updates to web.config:
var configuration = WebConfigurationManager.OpenWebConfiguration("~");
var section = configuration.GetSection("system.net/mailSettings/smtp") as SmtpSection;
section.Network.UserName = ConfigurationManager.AppSettings["myusername"];
section.Network.Password = ConfigurationManager.AppSettings["mypassword"];
configuration.Save();
The code actually updates the web.config. The code can be run at startup, but that would modify your web.config file locally as well. Another approach would be to run the code as part of a post deployment task with Azure.
How can we remove the server header response in IIS 8.0/8.5?
My current server report:
Microsoft-IIS/8.0
Microsoft-IIS/8.5
For IIS 7.0 I used the URLScan 3.1 however this is only supported for IIS 7.0 and not 8.x
There is another solution and in my opinion this solution is the best and safe.
You can use UrlRewrite module created by the Microsoft. The Url Rewrite module redirects your url and can also change your IIS server name in the response header.
You don't have to use redirect property. You can use just change the Server header value.
Here are the steps:
First, download UrlRewrite module from this link:
http://www.iis.net/downloads/microsoft/url-rewrite and install
it on your IIS server. After that, restart IIS by this command on cmd
console
iisreset /restart
Add the following item to the your web config file under the <system.WebServer> tag. You can write anything to the Value item as server name.
Finally we changed the IIS version name on the data's header. Restart IIS again. via cmd console.
Bonus: If you want to test your website to see if it is working or not... You can use "HttpRequester" mozilla firefox plugin. for this plugin: https://addons.mozilla.org/En-us/firefox/addon/httprequester/
PS: I tested it and it worked for me on the IIS server. Not on the has been created temproray IIS server by the Visual studio.
It is possible now to remove Server header from web.config starting from IIS 10.0 :
<security>
<requestFiltering removeServerHeader ="true" />
</security>
More details on how to remove all unwanted/unnecessary headers can be found here.
Please note that this hides server header from the "application", as do all the other approaches. If you e.g. reach some default page or an error page generated by the IIS itself or ASP.NET outside your application these rules won't apply. So ideally they should be on the root level in IIS and that sill may leave some error responses to the IIS itself.
Note there is a bug in IIS 10 that makes it sometimes show the header even with the modified config prior to 2019.1C. It should be fixed by now, but IIS/Windows has to be updated.
Add the below code in Global.asax.cs:
protected void Application_PreSendRequestHeaders()
{
// Remove the default Server header
Response.Headers.Remove("Server");
// Optionally, add your own Server header
Response.AddHeader("Server", "My-App/1.0");
}
This has been tested to work under IIS 8.5 and 10.0.
Unfortunately most of the recommendations you will find online for removing the "Server" header in IIS will not work for IIS 8.0 and 8.5. I have found the only working option, and in my opinion, also the best, is to use an IIS Native-Code module.
Native-Code modules differ from the more common Managed modules, as they are written using the win32 APIs rather than ASP.NET. This means that they work for all requests (including static pages and images) rather than just requests that past though the ASP.NET pipeline. Using a Native-Code module, it is possible to remove unwanted headers at the very end of the request, meaning that you can remove headers (including the "Server" header) regardless of where they have been set.
Binaries and source code of an example Native-Code module for removing headers in IIS 7.0 to 8.5 are available in the following article.
https://www.dionach.com/en-au/blog/easily-remove-unwanted-http-headers-in-iis-7-0-to-8-5/
Just use clear tag in custom headers segment in web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-Custom-Name1" value="MyCustomValue1" />
<add name="X-Custom-Name2" value="MyCustomValue2" />
</customHeaders>
</httpProtocol>
</system.webServer>
For dynamic headers, You can use this code in Global.ascx:
protected void Application_PreSendRequestHeaders()
{
Response.Headers.Remove("Server");
Response.AddHeader("Sample1", "Value1");
}
This is dead simple. Just create a custom module:
public class HeaderStripModule : IHttpModule
{
public void Init(HttpApplication application)
{
application.PreSendRequestHeaders += (sender, args) => HttpContext.Current.Response.Headers.Remove("Server");
}
public void Dispose(){}
}
And then register in web.config or applicationHost.config if you want machine wide implementation.
<system.webServer>
<modules>
<add name="HeaderStripModule" type="MyNamespace.HeaderStripModule" />
</modules>
</system.webServer>
URLScan has been discontinued starting from IIS 7.5, since its functionalities are supposed to be available through "request filtering" option (feature added in IIS 7.5).
But the URLScan's 'Remove server header' option does not look like having any equivalent in "request filtering".
As said on this answer and this answer to you question, you can emptied the Server with URLRewrite instead, which remains available on IIS 8/8.5 (with some update required for having its UI in IIS administration console).
It turns out, looking at this blog, that URLScan can still be installed on IIS 8/8.5, if lack of official support is not an issue.
I have not tested myself. Here are the steps:
Install IIS 6 Metabase compatibility (if not already there)
Install Isapi Filters (if not already there)
Install URLScan (from download-able installer, not from web platform installer)
Configure URLScan through its ini file (by default in C:\Windows\System32\inetsrv\urlscan)
Maybe some iisreset or even a reboot should be done. URLScan should be visible in IIS among Isapi filters
In IIS Manager, at the server level, go to the Features view. Click on HTTP Response Headers. You can add/remove headers there. You can also manage the response headers at the site level as well.
I have Sitecore as site root (which is running ok) and under it I need to have a bunch of asp.net applications running.
So far, created a virtual directory for the child application, turned it into an app. But as soon as I browse the child app it comes with this error message.
Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0246: The type or namespace name 'Sitecore' could not be found (are you missing a using directive or an assembly reference?)
Source Error:
Line 3264: </providers>
Line 3265: </roleManager>
Line 3266: <profile defaultProvider="sql" enabled="true" inherits="Sitecore.Security.UserProfile, Sitecore.Kernel">
Line 3267: <providers>
Line 3268: <clear/>
It seems that the child asp.net app is inheriting Sitecore settings which are coming from Sitecore web.config.
Any ideas?
This should be possible. You'll have to author a web.config for that non-Sitecore application in virtual directory, and overwrite the sections under <system.web> and <system.webserver> which reference Sitecore classes. This includes:
httpModules / httpHandlers (for these you should "remove all" and add those of that web app)
security section (put the default ASP.NET provider classes back)
in Sitecore main web.config add the path of this web app to IgnoreUrlPrefixes setting to let Sitecore know it should not handle requests to those
It might be something else, but you should get the general idea.
This answer is similar to Yan, but is different enough for a separate answer. Hope it helps.
Go into IIS and select the Child Application. Select Modules. Remove all the Sitecore related modules that are present. Don't worry, the parent Sitecore app will still retain these modules.
When you do this, you are actually changing the child app web.config, so you will see the elements removed in the web.config file like so.
<remove name="SitecoreConfigWatcher" />
<remove name="SitecoreHttpModule" />
You also may have to clear out some other inherited settings.
<profile enabled="false"><providers><clear/></providers></profile>
<roleManager enabled="false"><providers><clear /></providers></roleManager>