ASP and temporary files...
Discussion
One of my guys has written an ASP application that calls a style sheet, which in turn calls another application which itself gets some XML from a database. The stylesheet then renders said XML correctly in the main ASP application.
All tickety-boo - except that the IIS (v.6 on Win2003) creates a temporary text file (containing the XML data) in a temporary internet file folder under the system root.
We have confirmed that it is the web server writing the file by removing ISUSER account priveledges to this folder causing the app to fail.
The problem we have is that on our live servers our sysadmins don't want teh webserver account to write access to the file system.
So, does anyone know how to stop IIS writing this file, or if not, can we configure IIS to write the file to a place of our choice?
edited to add:
I reckon it's this that is causing the temp file to be created...
<xsl:variable name="OpenURLData" select="document($OpenURLAddress)"/>
where $OpenURLAddress is a full URL rather than a local file - does IIS get the data from the http request, save it as a local temp file and then read it in?
can this be done in memory rather than disc?
TIA
FG
>> Edited by FunkyGibbon on Thursday 14th July 08:34
>> Edited by FunkyGibbon on Thursday 14th July 08:35
All tickety-boo - except that the IIS (v.6 on Win2003) creates a temporary text file (containing the XML data) in a temporary internet file folder under the system root.
We have confirmed that it is the web server writing the file by removing ISUSER account priveledges to this folder causing the app to fail.
The problem we have is that on our live servers our sysadmins don't want teh webserver account to write access to the file system.
So, does anyone know how to stop IIS writing this file, or if not, can we configure IIS to write the file to a place of our choice?
edited to add:
I reckon it's this that is causing the temp file to be created...
<xsl:variable name="OpenURLData" select="document($OpenURLAddress)"/>
where $OpenURLAddress is a full URL rather than a local file - does IIS get the data from the http request, save it as a local temp file and then read it in?
can this be done in memory rather than disc?
TIA
FG
>> Edited by FunkyGibbon on Thursday 14th July 08:34
>> Edited by FunkyGibbon on Thursday 14th July 08:35
fg,
there's not really enough information here to provide a solution.
if you are simply using IIS to apply XSLT to XML data then the easiest way is to push this work to the client and let them render the xml for you. thus the problem vanishes instantly. It's not hard to give the client the details of the XML and XSLT and this will drop the load on your server.
If you have to have it done by IIS then I believe there is an option ( I cannot remember the location right now) to stop it caching the work.
put basically (from what you've said) as you have XSLT processing XML then the server is probably caching it so that next time a person requests the web page then it doesn't have to do this work again. No caching means no temp file but more work for your server
This could of course be completly wrong , I don't have the information to determine exactly what you're doing.
Finally if you have a good admin then it isn't hard to limit the access on the temp directory so that there are no sercurity reisks from having write access.
Peter
there's not really enough information here to provide a solution.
if you are simply using IIS to apply XSLT to XML data then the easiest way is to push this work to the client and let them render the xml for you. thus the problem vanishes instantly. It's not hard to give the client the details of the XML and XSLT and this will drop the load on your server.
If you have to have it done by IIS then I believe there is an option ( I cannot remember the location right now) to stop it caching the work.
put basically (from what you've said) as you have XSLT processing XML then the server is probably caching it so that next time a person requests the web page then it doesn't have to do this work again. No caching means no temp file but more work for your server
This could of course be completly wrong , I don't have the information to determine exactly what you're doing.
Finally if you have a good admin then it isn't hard to limit the access on the temp directory so that there are no sercurity reisks from having write access.
Peter
FunkyGibbon said:
cheers Peter, I'll see if I can find out why it has to be server side.
darthPaddington said:
Finally if you have a good admin then it isn't hard to limit the access on the temp directory so that there are no sercurity reisks from having write access.
Peter
That's my take on it too!
If they are doing this then you might want look at imposing a disc quota on the account.
It's easy and obvious to stop things like letting them run programs but with a little effort (and the policy editor I believe) you can limit them to only running withing the context of IIS directly and applying a quota will stop anyone from using a full disc as a DOS attack.
needless to say as well as no installing applications etc.
The only problem with this is that you might find it's a bit fiddly as it's not always obvios which parts of windows you need to grant access to.
Peter
Christ.
Sysadmins.
Bloody hell.
IIS has a cache directory. It caches stuff. All kinds of stuff. Maybe you can configure this to be somewhere else but IIRC Microsoft decide that it goes in a subdirectory underneath the executable installation.
You know...you want software to work at all...sometimes you have to compromise your ideals.
I once saw an entire system thrown out by feckless technies - that was delivering business benefit - because it ran on Windows with a "SQL" database instead of IBM Mainframe. Policy was all business apps ran on the 'frame at the time and your PC was just for Word.
Never let the techies decide how to run your business. They are
useless at it.
(I am 100% technical BTW. But I'm a businessman too!)
Sysadmins.
Bloody hell.
IIS has a cache directory. It caches stuff. All kinds of stuff. Maybe you can configure this to be somewhere else but IIRC Microsoft decide that it goes in a subdirectory underneath the executable installation.
You know...you want software to work at all...sometimes you have to compromise your ideals.
I once saw an entire system thrown out by feckless technies - that was delivering business benefit - because it ran on Windows with a "SQL" database instead of IBM Mainframe. Policy was all business apps ran on the 'frame at the time and your PC was just for Word.
Never let the techies decide how to run your business. They are
useless at it. (I am 100% technical BTW. But I'm a businessman too!)
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff