Did anyone observed or dealt with the following issue. I have couple web server (Dev, QA, Staging) all running Windows 2003, IIS 6.
Recently applied an update which uses the following lines of code:
sLogPath = Server.MapPath("../Templates/" & strFileName)
set fs = Server.CreateObject("Scripting.FileSystemObject")
If fs.FileExists(sLogPath) Then
That works fine on all dev systems but as soon as we moved it to QA I am getting an error:
The '..' characters are not allowed in the Path parameter for the MapPath method.
Line number xxx
Line number is to this line
sLogPath = Server.MapPath("../Templates/" & strFileName)
I tried replacing Server.MapPath("../Templates/") with Server.MapPath("/Templates/") but that gave me the root of IIS service (C:\InetPub\wwwroot) not the root of my sites. If I attempt to do Server.MapPath(strFileName) I am getting once again wrong path to the file because sites are not in IIS root but elsewhere on the drive.
Any ideas how this can be fixed?
The issue is you haven't got Enable parent paths enabled in the ASP application configuration.
Without it you are not permitted to use .. directory traversing in ASP functions.
For more information see Enable Parent Paths Is Disabled by Default in IIS 6.0
On a side note:
I tend to avoid the need for Parent Paths simply by configuring websites as separate web site instances in IIS rather than using %SystemDrive%\inetpub\wwwroot which is where the Default Website instance resides.
Doing this means that code like Server.MapPath("/") will be valid and point to the root of your site not the Default Web Site instance root.
Related
I have inherited an .NET app that is hosted on IIS. Previously it would have been its own site within IIS. Now in my Dev environment I have to run it under Default WebSite (in Production it will still run as its own site.
So in Dev I was having problems loading scripts and css files - so I right click Default Web Site in Dev and Add Application - call the new App - MyApp and point to the physical location on disk.
So previously style sheets would have been loaded:
href="/css/folder/mystylesheet.css"
and js files:
src="/jslib/jquery-1.9.1.js"
which worked fine when the application is hosted as its own site within IIS and which still needs to happen in Production (just not in my dev) So in dev I need to change the css and js as below:
href="~/css/folder/mystylesheet.css" (note ~ added)
src="./jslib/jquery-1.9.1.js" (note . added)
and now the js and css files for MyApp under Default website are loaded. However is there something simple I can do in IIS or webconfig to switch this behaviour on/off easily in Dev/Production rather than editing all the places where scripts and css files are loaded - as I know at some point a file will get checked into Production with the path incorrect
The other problem is there is numerous links throughout the site that are all relative so were /Link/Page.aspx which now break in MyApp hosted under Default Website
EDIT
Looking at the answer below from this question
In ASP.NET, many times you will need to use a tilde (~) to get the application's root directory, so your paths would look like ~/stylesheets/main.css
When you specify a path that starts with / you are indicating the server root so if you have you site in a virtual directory, it will not be taken into account, but if the site is hosted as the default site, the path will qualify:
Example: server named foo.net with site hosted in a virtual directory named app /stylesheet will translate to foo.net/stylesheet not foo.net/app/stylesheet
All my paths start with / (i.e going to server root) - what I need to figure out is there something I could add to web.config that for Dev would let me specify The Virtual Application MyApp needs to be taken into account (just for Dev - this could then be removed in Web Transform for Production web.config file
The short answer is no, there is not one single place where you can deal with the site's location. That's because there are many possible outcomes that you might want, including:
site served from IIS root folder and accessed at root of domain (or not)
site served from IIS subfolder and accessed at same path (or not)
IIS rewrite rules (inbound and outbound), which adds layers of mapping between public and private paths
sites mapping to subdomains, DNS wildcard mapping (where requests are distinguished by hostname), etc
sites mapping to child applications, inheriting or not inheriting rewrite rules (and other configuration)
all of the above
At the same time, there are many places where you interface with paths:
internal physical paths, usually for disk access, and usually requiring mapping of virtual path
internal virtual paths
internal ASP.NET paths, like virtual paths except that they can be app-relative (using ~), which IIS doesn't always recognize
public-facing paths
all of the above can be relative or absolute
So yeah, it's a mess.
For your case, the simplest thing is probably to make the development environment mirror the production environment. Unless you're moving the live site, delegating all the path references to a configuration-aware function is probably more trouble than it's worth.
The ~ is added to make the path relative to root directory. One suggestion is to move the folder up a few levels.or down a few levels to make sure your project is in the correct directory. Hope this works
If I make a site manually via the inetmgr app (IIS 7) and give it a site name and physical location (as well as changing its app pool to .net 4) it all runs fine and picks up the web.config file.
However if I set up the same site on the command line using appcmd it for some reason ignores the web.config file, the inetmgr shows the site working and the files being there, but under "Configuration Editor" there are no entries there from the web.config file.
The command line app cmd is run from a build script, but the method to do this is below:
def create_web_site(site_name, site_location, site_port)
delete_command = "#{$file["appcmd"]} delete site #{site_name}"
result = system delete_command
puts "Failed to delete site on IIS: #{$?}" unless result
add_command = "#{$file["appcmd"]} add site /name:#{site_name} /bindings:http/*:#{site_port}: /physicalPath:#{site_location}"
result = system add_command
raise "Failed to add site on IIS: #{$?}" unless result
set_app_pool_command = "#{$file["appcmd"]} set app #{site_name}/ /applicationPool:\"ASP.NET v4.0\""
result = system set_app_pool_command
raise "Failed to bind site to .net 4 app pool on IIS: #{$?}" unless result
start_site_command = "#{$file["appcmd"]} start site #{site_name}"
result = system start_site_command
raise "Failed to start site on IIS: #{$?}" unless result
end
You don't really need to know rake/ruby to see it is running appcmd and deleting a site if it exists, then adding the new one, using the .net 4 app pool then starting the site. This all works fine and I can see the 2 sites which are identical as far as I can tell (other than the one I am manually creating via the GUI has a different port to the other to stop conflicts).
Is there something im missing from appcmd which the GUI does for you when setting up sites?
After tinkering around the issue is down to the slashes between folders being incorrect for IIS. It all appears to work but wont pick anything up, so where my site directory was something like:
c:/some_folder/some_site
in my script I had to swap them to:
c:\some_folder\some_site
Everything worked fine, however as the "\" character usually signifies a skipping or ignoring on the following character I just did it as a string replace on the first string rather than entering it in as the correct way to begin with.
I want to get CF9 with IIS 7 setup locally to run with multiple domains.
I have read this one but it doesn't say anything about the actual setup.
Need help with multiple URL setup on local CF9/Jrun install
I setup IIS so that I can start 127.0.0.1/domain1/index.cfm The page loads properly
but all subsequent links fail with
Could not find the included template: /_/definesession.cfm
But I see the file when typing in file:///C:/InetPub/wwwroot/domain1/_/DefineSession.cfm
The files are there but apparently the server is only reading the directory correctly
If I test http://127.0.0.1/domain1/_/BrowserDetect.cfm with no includes just a self contained file it executes properly.
The path in IIS is set to C:\InetPub\wwwroot\domain1
The bindings hostname is just domain1 no TLD
Also the second instance 127.0.0.1/domain2/index.cfm is working correctly. And here as well including subdirectories is failing.
ADDITIONAL NOTES: (added 1/3/12)
I guess it has to do with the CF mapping. I now moved the code to c:\coldfusion9\wwwroot\domain1_... and it sort of works.
In other words I start the program here: C:\inetpub\wwwroot\domain1\index.cfm Inside that index is for instance
But it executes the file located here: c:\coldfusion9\wwwroot\domain1_\definesession.cfm Just couldn't find anything in the web about mapping a local CF9 to that situation. Any idea??? –
You might have a ColdFusion mapping for "/" that needs to be adjusted.
OK I fixed it. There were multiple issues:
For whatever reason there were some issues with IIS and I had to reinstall it.
I had to make sure 9.0.1 was installed
I had to run Webserver Configuration Tool multiple times to actually get the Handler Mappings in order.
http://127.0.0.1/domain1/ was wrong - it must be http://domain1/ etc.
I forgot to add the domains to the host file on the machine - stupid me
I had to redesign my mapping to avoid overlaps between domains (i.e. mapping CFCs to /_/cfc/ on all domains needed to have different mapping names.
Now I have several different domains on my local machine and they work just fine.
I have a Classic ASP website which we have moved from IIS 6 to Win2k8 and IIS 7. Within the website folder structure, is a Virtual Directory called Products containing JPGs that are physically stored elsewhere on the same server.
Within a web browser, any of the Product JPGs display correctly on the page. E.g. http://www.MySite.com/images/poducts/widget.jpg works a treat.
However, this folder is unavailable when trying to access it in ASP code, using the FileSystemObject - all other files/folders are there except the Virtual Directory. Here is an example ASP code snippet:
Set objFSO = Server.CreateObject( "Scripting.FileSystemObject" )
Set objBaseFolder = objFSO.GetFolder( Server.Mappath( "../../Images" ) )
For Each objFolder In objBaseFolder.SubFolders
Response.Write( objFolder.Name & "<br>" )
Next
Set objFolder = Nothing
Set objBaseFolder = Nothing
Set objFSO = Nothing
Additionally, Persit's ASPJpeg Com Object has no problem opening and saving JPG files to/from this Virtual Directory from ASP code.
In IIS7, the website has an Application Pool, and I've tried all manner settings for its identity to no avail. I have also tried applying various security settings (IUSR_, Network Service, et al) to the physical folder that the Virtual Directory points to - even granting full control to "Everyone" at one point.
It really seems like the ASP process does not have permission to Virtual Directories. If anyone has and idea on how to solve this problem then I'd be most greatful.
Using FileSystemObject to do this is never going to work because it only works on the physical file system. It does not know about or understand virtual directories - this aspect of your site is managed entirely by IIS.
It is not a question of permissions it is a question of the directory not physically being there so browsing the physical file system will never see it
IIS manages virtual directories:
Navigating to an image in your browser works because IIS automatically maps the virtual path to the appropriate physical path.
Using AspJpeg works most likely because it uses calls to Server.MapPath to resolve the given path into a physical path
This cannot be an issue of permissions since you stated yourself that AspJpeg can read and write to the virtual directory fine plus you can access it through your browser fine.
I vaguely remember having a problem like that and the culprit was Server.Mappath. To solve it I needed to map to a file inside the folder and then remove the file part
Server.Mappath( "../../Images/dummy.gif")
the "../" notation is not always allowed for security reasons. If you have access to IIS see if it is enabled or disabled.
I've just create a new ASP.NET Web Application in VS2010, and set it up as an application in IIS7.
Not sure if this is relevant, but the code physically resides in the \myserver\projects\epeui\epe folder (the projects folder is the root of my default web site). The application hangs off the root of this machine's default web site: http://myserver/epe/. And is configured as an application in IIS.
Normally, I used URLs that are relative to the application root, so my CSS files are in /styles/, my images are in /images/ and my JavaScript files are in /scripts/.
Given that the application is configured as such in IIS, to access my logo, I would expect to use /images/mylogo.png, an application-relative URL.
However, this doesn't work for this site; instead I need to use parent paths (../images/mylogo.png) or URLs relative to the default web site (/epe/images/mylogo.png). Neither of these are very good for portability reasons.
I've also tried using the tilde to use URLs that are supposedly relative to the virtual path (i.e. the application root) = ~/images/mylogo.png
I swear I've done this a thousand times before but clearly screwing up somewhere... Any suggestions?
Can someone at least confirm that, for a standard application in IIS, /mypage.html should reference http://myserver/myapp/mypage.html and not http://myserver/mypage.html?
/mypage.html is going to map to the root http://myserver/mypage.html, this is correct behavior
The ~ on a SERVER SIDE control will map to the application root (so <asp:HyperLink NavigateUrl="~/mypage.html"...> will map to http://myserver/myapp/mypage.html
I have, in the past, especially with css and javascript files had to use <%= Request.ApplicationPath %>/myPage.html. Sometimes it's good to define that as a global variable in the global.asax.cs so you can use it all over. Request.ApplicationPath in your instance will be "/myapp"
I've struggled with this a lot too.