We are using IIS7, currently in classic mode. We have an ActiveX control on our site that needs a DLL to get downloaded to Client. To allow this to happen, we are removing the Execute permission for the DLLs and EXEs (in Handler Mappings).
The problem is that this method prevents any DLL or EXE from being used by the web application. Is there any way to configuring IIS such that a specific DLL can get downloaded, without a blanket removal of Execute permission?
Make another application, in which the handler mapping execute permissions are removed. Store the content in this application and redirect the users to this application.
Related
When using selfhost .Net Core 2.x, all the build artifacts are statically served by default, since the default directory is the same place as the binary/exe.
This means if one knows the names of the dlls, they can just request
them at /Whatever.dll, or they can also get any config files by name,
i.e. appSettings.
If you change things so that that the root directory is different or that directory is not in the VFS, /metadata stops working.
Is it possible to have /metadata work, but not allow the service's dlls etc to be statically served?
I have tried restricting the paths. This will keep settings / dlls / exes from serving, but the /metadata page will come up completely blank.
The /metadata page isn't related to the static file directory location, you may have caused a Startup Exception that's impacted how it works. If you can put together a stand-alone project on GitHub which shows the issue I can investigate.
Only extensions in Config.AllowFileExtensions can be served, you can remove .dll from being served with:
Config.AllowFileExtensions.Remove("dll");
.exe aren't servable by default, if you can download them you might be downloading them with .NET Core's static file handler instead.
It's common practice to have the WebRoot outside of the project root which for .NET Core is typically /wwwroot.
edit: Updated suggestion to remove the badness.
What I ended up doing at first was to add a .UseWebRoot() onto the
builder, then later switched from the selfhost ServiceStack template
to the web template per Mythz's suggestion. The web template was
set up in a way that solved my problem.
Thanks again.
We are using VS 2012 with TFS 2012.
We want to prevent some users to view particular source files in a project,
We know how do this,Actually by right clicking on the files on the source control window and manage permissions in security tab.
The problem is that when we prevent a user to view or change a file such as HomeController.cs
the user can't build the project and the vs IDE says that the file does not exist,
How we prevent access a file with the ability of successful building project for the user
If you prevent read / view permission then how can the compiler access the file in order to build it? If the compiler can see the file then so can the user.
Are you sure that you want to prevent these users from even seeing the file, or do you just want to prevent them from changing the files? If it's the latter then you can simply remove the permission to check-in.
There is another avenue that may be of use in your situation. Split the project up into libraries and only combine all the libraries on the build server.
The developer can build but not run on their machine. With gated check-ins the build is made available.
This works especially well if the project is web based and the build server deploys the assemblies to a web server that the developer can view.
Otherwise the notes on obfuscation and decompiling stand.
I am trying to find out how to host an ISAPI DLL in Azure. In addition to the DLL, I'll need to deploy supporting files in subdirectories (javascript & css files). And two of these subdirectories can have their contents changed by requests handled by the DLL, so I need to ensure that the account executing the extension has write permission for these.
It would seem that the key to all of this is using a startup task to call appcmd to script all the IIS changes somehow, and I think I need to do the following:-
Deploy my ISAPI DLL and supporting files with my ASP.NET website
Create a startup task which will call a batch file utilizing appcmd.exe to do the following:-
Create a dedicated app pool with its managed pipeline mode set to Classic, and using a known user account
Create an IIS application pointing to the directory where my ISAPI dll resides
Ensure the application is configured to allow unknown ISAPI extensions
Alter the permissions of the required subdirectories so the user account associated with the app pool has write access
I've only just started exploring Azure, so my experience with it is very thin on the ground. Is what I'm hoping to achieve actually achievable? And if so, am I on the right track with regards to the steps required? They mimic what I need to do if I'm setting up this ISAPI DLL in the traditional IIS environment I'm used to dealing with, but please let me know if the rules are different with Azure.
Looks like a good sequence, however, the startup tasks actually run before IIS is completely configured. The 'OnStart' event in the RoleEntryPoint is called after IIS is set up, so it's probably easier to use the IIS application that Azure creates for you, and reconfigure it to include your ISAPI stuff.
Well the only thing bothering me here is that you're modifying data on the 'deployment drive' (E: for that matter). You shouldn't be doing this.
Instead, think of an other solution. You could create a LocalResource holding your javascript and CSS files. Then, when your role starts (Richard has a valid point about startup tasks), use ServerManager class to do the following:
Register the ISAPI dll
Add 2 virtual directories under the website created by Azure and point them to the LocalResource.
Modify the code of your ISAPI dll to modify JS/CSS files in the LocalResource
When developing in Web/WorkerRoles, you need to keep in mind that you should only manipulate files in a LocalResource.
We're talking about a simple webapp.
So I have a file called "modulev2.cgi" which is part of a trusted 3rd party online payment company. This file has to be put in a folder named "cgi-bin". For windows IIS environnement the file is renamed "modulev2.exe" and put in the same directory. This is what the documentation says.
Module is called as this :
FORM ACTION=../cgi-bin/modulev2.exe METHOD=post
with a bunch of parameters. It should not download when called of course but execute.
And indeed it does work in my dedicated server, provided the "cgi-bin" folder and the file in have "execute" setting level in IIS.
So to the point, would I be able to set the rights to execute to this file in Windows Azure ? If yes, how to script such a process ?
Any help greatly appreciated.
Thanks !
The best way to do this is to script it out locally against your IIS using appcmd.exe. You want to add your CGI handler programmatically. By default, IIS in Windows Azure is already running CGI/Fast-CGI, so you don't have to install it, it should be ready. I think you need to add it to the CGI restriction list and add your handler mappings.
http://technet.microsoft.com/en-us/library/cc732851(WS.10).aspx
Once you have a .cmd file that will correctly configure your local IIS settings, you can use that as the basis for a Startup task in Windows Azure to bootstrap the role.
http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-31-Startup-Tasks-Elevated-Privileges-and-Classic-ASP
http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-34-Advanced-Startup-Tasks-and-Video-Encoding
I'm dealing with an issue where there was a site setup, and the default.htm used an iframe which pointed to an ASP directory. It seems like the ASP directory isn't readable and not processed - is there anything special that needs to be done to the ASP directory like permissions-wise?
wwwroot/sitename
<iframe src="ASP/file.asp"></iframe>
wwwroot/sitename/ASP/file.asp exists, and several other asp files but they aren't getting referenced by the iframe.
Update: I'm getting a 404..
The page cannot be found
I think I have to create a virtual directory and name it ASP. I never use IIS though - does anyone know how this works? And would I need to restart IIS after creating the virtual directory?
Update #2: More info..
Execute permissions: Scripts Only
Application name: asp
For Authentication Methods, "Integrated Windows authentication" is checked
Local Path: Read
Update #3: I can access asp/file.htm file fine. Can anyone provide code for a simple test I could do to see if its working properly ( I have no ASP/VBScript experience )..
one of the top of the pages contains <%# LANGUAGE="VBSCRIPT"%>
Is this IIS6 by any chance? In IIS, under Web Sites there is a folder called Web Service Extensions. Make sure Active Server Pages are set to Allow and not Prohibited!
When you create a virtual directory for an ASP site in IIS, you have to make sure it is allowed to execute scripts. What version of IIS are you using? In 5.0 and 6.0, there should be a checkbox Run Scripts (such as ASP). Make sure that's checked.
Try putting a test.html file in the root directory of the site and then try to open it through wwwroot/sitename/asp/test.html - .html files won't be processed by asp.dll and so should display if the site is setup correctly even if there is some kind of asp.dll problem.
If you can't see a html file then I guess you will need to configure the website in IIS (not sure if a virtual directory is necessary from the information given) - check the 'home' tab to see if the path to the application is correct first.
If you can see the html file then I'd guess that asp is not properly installed (but that is a guess).