Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Use Isolated Storage for Stateful Network-deployable .NET Components : Page 2

Isolated storage is a .NET security feature that assigns each application a unique storage area that is fully isolated from other applications and essentially private. Isolated storage provides true isolation in the sense that the identity of an application or a component uniquely determines the root of a virtual, sandboxed file system. This form of data storage is well suited to partially trusted applications in general and ASP.NET applications in particular.




Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js

Date: 1/31/2018 @ 2 p.m. ET

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.

  1. Open the folder with Windows Explorer.
  2. Right-click and select the Properties menu item.
  3. From the subsequent tabbed view, pick the Security page.
  4. 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).
  5. 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 trick—using in-memory streams.

The MemoryStream 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, _ FileMode.CreateNew) WriteContents(file) file.Close() ' Use MemoryStream to create a memory buffer Dim ms As MemoryStream ms = New MemoryStream() WriteContents(ms) ms.Close()

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 class.

Dim s As String = "Hello, world!" ms.Write(Encoding.ASCII.GetBytes(s), _ 0, s.Length)

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 trick—changing the permissions on a file or a folder—is 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, but—that's the point—not 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)

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date