BTW this is not something I am want but is a requirement I must follow. My requirement is to create a user interface that will allow users to disable Classic ASP while allowing ASP.NET 1-4 applications run. Can anyone think of a use case were a user would want to do this?
Sure, if you were a web-host offering partial access to a webserver through an application that emulated some of the relevant IIS options, then not only would customers not want the added risk of unneeded script/executable systems running, but you wouldn't either, so you'd want it turned off unless they went in and explicitly turned it on because they needed it.
Indeed, software for this use-case already exists.
Jon's comments about reducing a site's attack surface by removing unwanted features is very valid. You should ideally just run what you need and no more.
There are a number of ready made commercial solutions to this problem such as Plesk, but they may provide too much functionality for your needs.
You could write your own functionality:
If this is IIS6 then you should take a look at the ADSI API which is surfaced via the System.DirectoryServices namespace:
Using System.DirectoryServices to Configure IIS
To enable/disable scriptmaps you need to manipulate the ScriptMaps metabase property for a site:
ScriptMaps Metabase Property (IIS 6.0)
If this is IIS7 then take a look at the Microsoft.Web.Administration managed API. In IIS7 you want to manipulate the handler mappings for a site:
Handlers <handlers> - IIS.NET
In all cases, the user must be a member of the machine's Administrators group.
Related
I'm completing a feature that was started by a previous developer. I notice that he's loading settings from the db in the Global.asax Application_Start method and puts the settings into HttpContext.Current.Application["SettingName"].
In development this works fine on my machine. If I'm not mistaken though this looks like in production it's going to load the data once when the application starts for the first user but settings will not be available to the application for any subsequent user.
Can someone please confirm or deny my suspicions?
The HttpContext.Current.Application["SettingName"] is a static property. It will be available to the next subsequent users as well. But you can not change it that easy, especial if you use web garden.
You can read more details here: Using static variables instead of Application state in ASP.NET
I do not know how the design is, but you can use a simple static dictionary for the same... of direct read from the database your parameters, or from web.config.
I generally wouldn't touch the HttpContext in Application_Start. In fact, I don't think IIS's Integrated Pipeline will even let you do that.
With integrated pipeline, Application_Start could get fired before any requests even hit the server, such as IIS 8's Application Initialization.
I recommend that you place the settings in the web.config file and use the ConfigurationManager object to read those settings. This is a lot simpler, as there is no need to store them in the HttpContext.
e.g.
<configuration>
<appSettings>
<add key="SettingName" value="SettingValue" />
</appSettings>
</configuration>
Doing this means the settings will be available to the entire ASP.NET application - there is no need to store them in the HttpContext.
There is a caveat that when you update the web.config file the application pool for the ASP.NET site will be recycled. But the consequences of this all depend on what that site is doing with, for example, session state and caching. Recylcing the application pool will reset those, but that's for another question.....
EDIT:
Based on the comments, it sounds like session state will help you here. With session state, you can store the user specific settings so that they do not interfere with other users.
I am currently trying to migrate a legacy ASP application from Windows Server 2000 and IIS5 on to Windows Server 2008 and IIS7. The authentication for this application uses an ISAPI filter. Both the application and the ISAPI filter work in the new environment except for one problem. The application in question is set up to be the root application (as in you access it by going to http://hostname/application.asp). If I access it by the stated URL, it asks for my authentication details, the ISAPI filter gets passed the correct login details and then does its thing. Then I added a default document to IIS7 to point to application.asp. Now if I access the application by going to http://hostname, the ISAPI filter gets passed the wrong login details. The ISAPI filter implements this method:
DWORD CMyISAPIFilter::OnAuthentication(CHttpFilterContext* pCtxt, PHTTP_FILTER_AUTHENT pAuthent)
In it, the pAuthent object gets passed in by IIS when it calls the ISAPI filter and has the pszUser property which normally holds the value entered in the authentication dialog. In my case (when accessing the website by using the default document entry), the pszUser property holds the value of the Windows account that is running the application pool instead. Just to make things clear, the ISAPI filter gets passed the correct value if I type in the application.asp part.
I'm quite stumped at this problem and have no clue as to how to solve it. To make matters workse I can't really rebuild/modify the ISAPI filter and am quite the beginner when it comes to IIS administration.
I have also found that authentication works if IIS does not have the Default Document feature installed. Without this feature the default document does not work (naturally) but authentication does. It's only after I add the Default Document feature that authentication breaks.
Thanks for your help!
Sounds like the web site is configured to use integrated security on the root level. Make sure you remove the checkmark from the Integrated Windows Authentication checkbox in the Directory Security-Tab.
The Node "Web Sites" can be configured as well. So make sure you don't miss that one ;-)
EDIT: Damn i can't upload a picture. Would make it easier for you to find the setting.
I'm currently looking into url-rewriting and how it should be done right and hope you have some inputs here.
At the current stage of development only the kind of url-rewriting I'm interested in is adding facebook like behavior to businesses to which we provide services on our site, i.e. www.mysite.com/ShowBusinessInfo.aspx?id=1 should be rewritten to www.mysite.com/HostedBusinessName. - The idea is that when a business registers on our site they can choose whatever the last part of the url should be.
What would be the best way to support this feature? Custom IHttpModule, Global.asax (I'm afraid that this is too slow?), UrlRewriter.net/UrlRewriting.net or a completely different solution.
The site is developed in asp.net and runs on IIS 7.5.
I've actually done something like this before and this is the article I used as a resource: http://stweet.wordpress.com/2010/03/15/creating-a-new-website-programmatically-on-iis-using-asp-net/
This article will tell you how to programmically add a web site to your IIS using C#. Keep in mind that depending on how your IIS and DNS is setup, you may need to also modify your DNS server. You can find various scripts for doing this here: http://msdn.microsoft.com/en-us/library/ms682129%28VS.85%29.aspx
Hope this helps!
If you have fairly simply rewriting rules, I'd use an IHttpModule that attempts to match the URL's LocalPath property with a value in your DB, and then calls context.RewritePath(string).
If you have more complex stuff, then I'd start looking at UrlRewriting.NET or the routing options in ASP.NET.
Is it possible to use a small .NET page to set folder permissions on some folders on the server where it resides? What is the code or objects that can be used for this? I am on Windows Server 2003.
Basically I want to hit the page with a GET or POST and have it run and check and/or update the permissions on a folder.
There's a number of possible ways to approach this.
One is to use the FileIOPermissions class, which allows you to specify permissions on files and folders.
The other option is to use the DirectorySecurity class within the System.Security.AccessControl Namespace, and specifically the SetAccessControl Method of that class.
This second method should provide you with much more granularity and control over the setting of permissions as the System.Security.AccessControl namespace allows you to programmatically create or modify discretionary access control lists (DACLs) and system access control lists (SACLs) for a number of protected resources such as files, folders, and so on.
Irrespective of the method you choose to perform the permission setting, you will need to be mindful of the account that your ASP.NET-driven code is running under. You say you are using Windows Server 2003, so you're probably using IIS version 6.0. By default, IIS 6.0 will run all user code under the "Network Service" account, which is a low-privilege account and will have limited permissions outside of the IIS processes and the website hierarchy. You can read the MSDN article, "How To: Use the Network Service Account to Access Resources in ASP.NET" regarding accessing resources on the server side and exactly what access you will have under this account.
Depending upon the exact nature of what you want to do, you may also need to look into ASP.NET Impersonation to enable your server side code to run under the context of a different account. See the MSDN article, "How To: Use Impersonation and Delegation in ASP.NET 2.0" for more information on that.
You can use the FileIOPermission class to do this. Just make sure the user under which the website is running has this permission to do all the security settings.
Does anyone know a web based editor for the web.config? I want to offer the possibility of changing and adding settings through a nice web interface.
Update: I am aware of the security issues but still i want to make it possible. The application is an internal app which is not available for outside. I configure authorization within web.config and want be able to administer the users who are able to access the app. Furthermore I have some app settings which i want to be updateable. E.g. mailserver, Connectionstring, etc..
I tend to agree with GregD on this point... Exposing the web.config is not a good idea at all. If you really want the user to be able to configure some settings, provide an interface for it, which allows the user to set the values as per requirement. Check out the built-in ASP.NET website administration tool if you need an example.
There is a good reason why the web.config is not readable from the internet. Don't do it.
Edited to add
What is it that you wish to accomplish by opening up the web.config? The web.config is where you store database connection strings, turn debug off/on, show error messages locally or remotely, etc., etc. Opening up your web.config to "editing" via a web interface, is really asking for someone to hack it, thus gaining full access to your application.
I agree you probably shouldn't do this.... but in going against the grain since we are all adults here...
It is possible to modify the web.config if your website is running in full trust mode. If you're hosted on GoDaddy for example then you are probably out of luck.
That being said you could leverage an admin page I wrote for BlogEngine which will allow you to edit any file you have granted the AppPool service permission to edit. You would probably want to remake this into a user control and then add it to a protected url address and/or folder.