The Case of ASP.NET Applications
Just a few weeks before releasing version 1.0 of the .NET Framework, Microsoft decided to change the default account for the ASP.NET runtime process. Unlike ASP, ASP.NET does not run applications within the context of the LOCALSYSTEM account. ASP.NET applications are considered partially trusted applications and, subsequently, pages accessing the file system explicitly need to be granted write permissions to operate safely and effectively. How can you work around this I/O limitation? (See Sidebar: Security Zones
One thing you can do is change the security permissions on the folder that contains the ASP.NET application. You must do this once during the setup of the application. Here's a step-by-step guide.
- Open the folder with Windows Explorer.
- Right-click and select the Properties menu item.
- From the subsequent tabbed view, pick the Security page.
- Add the ASP.NET account to the list of accounts enabled to operate on the folder by clicking the Add button and selecting ASPNET from the list of available users. (See Figure 3).
- Next, return to the previously selected Security tab, highlight the newly added ASPNET account and add write permissions. (See Figure 4).
Figure 3: Select the ASPNET user account and click Add to be able to edit the default permissions.
Figure 4:Select the ASPNET account and edit the permissions accordingly.
After this treatment the ASP.NET application based in that physical folder will be able to create and update local files.
Normally an ASP.NET application needs to create local files to park some data or to persist some settings. If the name of the file is known, not subject to change, and a default copy of the file is provided at setup time, you could also apply the algorithm above to the individual file rather than to the whole folder.
In other situations ASP.NET applications need to create temporary files that don't survive the session or even the single request. In this case you can consider employing a simpler trickusing in-memory streams.
class works in much the same way that a disk file stream does. The key difference is that MemoryStream creates a stream whose backing store is memory rather than a disk file. Let's compare the code necessary to save a file to a file stream and to a memory stream.
' Use FileStream to create a file
Dim file As StreamWriter
file = New StreamWriter(fileName, _
' Use MemoryStream to create a memory buffer
Dim ms As MemoryStream
ms = New MemoryStream()
The MemoryStream class encapsulates its data into an array of bytes and makes it available only in that form. You can write strings to a MemoryStream object only after you convert them to an array of unsigned characters. Unfortunately no method on the String class provides that capability. To do this job you must resort to the GetBuffer
method of the Encoding
Dim s As String = "Hello, world!"
It is also easy to read back strings from a MemoryStream object. In this case you use the GetString
method of the Encoding class, as shown below.
' GetBuffer returns the contents of the stream
Dim buf As String
buf = Encoding.ASCII.GetString(ms.GetBuffer())
While the previously discussed trickchanging the permissions on a file or a folderis just a hack, memory streams represents an interesting option because they can reduce the need for temporary buffers and files in an application.
Let's make a more general consideration about partially trusted applications. The CAS infrastructure prohibits them from accessing the file system to avoid the risk that they could perform malicious code. However, one thing is getting a full access to the file system and all another one is persisting some user-defined bytes to disk. The second option still requires that the application accesses the file system, butthat's the pointnot necessarily the whole file system. This rather straightforward observation is at the root of the CAS feature called isolated storage
(See Sidebar: When You Shouldn't Use Isolated Storage