Samurai Programmer.com - .NET Upgrade

.NET 2.0 and Access Databases

Greg Varveris — Sat, 24 Jul 2010 03:51:28 GMT

For an internal application at my company, very particular users have the rights to download an MDB that contains links to a replicated instance of a DB. This was done so they could create their own queries without any assistance from IT - essentially a poor man's Cognos or Reporting Services. This worked fine in .Net 1.1.

We are currently in the process of upgrading this application to .Net 2.0 and one of the developers on the project brought to my attention that the download was failing with a message stating:

She did some research and uncovered this forum post with step by step instructions on how to re-enable the downloading of an Access database.

Please keep in mind, though, that this was done for security purposes - so any page that links to a secured Access DB - should be secured in a variety of ways:

1. Code Access Security:

 1: <PrincipalPermission(SecurityAction.Demand,
_ 

 2: Authenticated:=True,
_

 3: Role:="Secured
User")> _

This should be placed in the code-behind on the page with the link to the file. As you can see, the "Role" property will secure this page to just a user in a particular role. If you have a page that is accessible to multiple roles, you can stack the class attributes on top of each other as seen here:

 1: <PrincipalPermission(SecurityAction.Demand,
_

 2: Authenticated:=True, 

 3: Role:="First
Role")> _

 4: <PrincipalPermission(SecurityAction.Demand,
_

 5: Authenticated:=True, 

 6: Role:="Second
Role")> _

 7: Partial
Class PagesToBeSecured

2. File Access Restriction:

Also, by putting a web.config in the folder that houses the Access DB, you can secure access to the contents of a particular folder. For example with a structure of:

 1: Root/Downloads/Database/db.mdb

You can put a web.config in the "Database" folder that restricts access to that folder to a particular user/role/etc. For example, the web.config in this example would look something like:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<system.web>

<authorization>

<allow roles="Role
1" />

<allow roles="Role
2"/>

<deny users="*" />

</authorization>

</system.web>

</configuration>

As you can see, we are only allowing users in roles Role 1 and Role 2 to access the contents of this folder. If any other users attempt to access the file, they will get a Page Cannot Be found exception.

In conclusion - if you are going to remove this particular restriction in IIS to allow users to download Access DB files directly from your web application - then you shouldn't completely discount security and you implement both of the following measures.

Enjoy!

ASP.NET 2.0: Textbox ReadOnly Property

Greg Varveris — Sat, 24 Jul 2010 03:42:12 GMT

This has been documented in numerous places including here, here, here (with an incorrect fix) and here.

Essentially, if you set the Readonly Property of a textbox using either the XHTML or in the code-behind, any changes you make to the value of that textbox client-side (ie: javascript) will not be persisted across postbacks. I had found this method extremely effective for Calendar controls and what-not. You just provide a link to a popup and then when the user selects an item in the popup, you can populate the underlying Textbox with the value from the popup. Unfortunately, out of the box, that functionality has been taken away.

The code in the Textbox that actually signals to the page that textboxes using the ReadOnly property should not be saved in ViewState is in a few places:

Protected Overrides Function SaveViewState() As Object

If Not Me.SaveTextViewState Then

Me.ViewState.SetItemDirty("Text", False)

End If

Return MyBase.SaveViewState

End Function

  

Private Shadows ReadOnly Property SaveTextViewState()
_

As Boolean

Get

  

If (Me.TextMode
= TextBoxMode.Password) Then

Return False

End If

If (((MyBase.Events.Item(EventTextChanged) Is Nothing)
_

AndAlso MyBase.IsEnabled)
_

AndAlso ((Me.Visible AndAlso Not Me.ReadOnly)
_

AndAlso (MyBase.GetType Is GetType(TextBox)))) Then

Return False

End If

  

Return True

End Get

End Property

In the SaveTextViewState() method, part of the conditional statement specifies that if the ReadOnly property is set to true, then do not save the ViewState.

Also, in the LoadPostData() method, there is another check to make sure that the control's ReadOnly property is not set to true before it loads the data from the form post:

Protected Overrides Function LoadPostData(
_

ByVal postDataKey As String,
_

ByVal postCollection As _

NameValueCollection) As Boolean

MyBase.ValidateEvent(postDataKey)

Dim text As String = Me.Text

Dim text2 As String =
_

postCollection.Item(postDataKey)

If (Not Me.ReadOnly _

AndAlso Not [text].Equals(text2,
_

StringComparison.Ordinal)) Then

Me.Text
= text2

Return True

End If

  

Return False

End Function

If the ReadOnly property is set to true, then it will not set the Text property of the TextBox to be the value from the Form post.

The fix that people are touting is relatively simple. In the code behind of the page, you can simply add the attribute manually to the TextBox like this:

Protected Sub Page_Load(ByVal sender As Object,
_

ByVal e As System.EventArgs) Handles Me.Load

With Me.txtTest

.Attributes.Add("readonly", "readonly")

End With

End Sub

And while this would work - this just feels like a bandage. Plus, if you have a big web project you are converting from .net 1.1 to .net 2.0 that contains TextBoxes all over the place that have the ReadOnly=True set, then this would be a lot of code to include on every single page. Even if you have a shared function somewhere that you can call - that means you still have to call the function for each Textbox that you wish to set as ReadOnly.

An alternative is to create your own TextBox class that inherits from the existing TextBox and handles the ReadOnly property in the fashion mentioned above. Any example of the code for the new TextBox is as follows:

Namespace WebControls

Public Class TextBox

Inherits System.Web.UI.WebControls.TextBox

  

Public Overrides Property [ReadOnly]() As Boolean

Get

Return False

End Get

Set(ByVal value As Boolean)

If value Then

Me.Attributes("readonly")
= "readonly"

Else

Me.Attributes.Remove("readonly")

End If

End Set

End Property

  

End Class

End Namespace

That's fine for new TextBoxes, but what about my hundreds and hundreds of TextBoxes that are already in my application? Well, .Net 2.0 allows you to use something called tagMappings in your web.config. Essentially, they are a way to redirect the compiler to use a different class for an existing mapping when it compiles your pages. From MSDN:

"Defines a collection of tag types that are remapped to other tag types at compile time."

So, how do we use this neat feature to solve this problem? Well, in the web.config, we will tell the .Net compiler to use our new TextBox control instead of the existing System.Web.UI.WebControls.TextBox control. In order to do this, you simply add the following to your web.config:

<pages>

<tagMapping>

<add tagType="System.Web.UI.WebControls.TextBox" 

mappedTagType="WebControls.TextBox"/>

</tagMapping>

</pages>

The tagType attribute is the existing tag you would like to change (System.Web.UI.WebControls.TextBox) and the mappedTagType is the new TextBox control from above.

With this tag added in the web.config - whenever you have the following in a page:

<asp:TextBox runat="server" 

ID="txtTest" 

ReadOnly="true" />

Your application will use the TextBox defined directly above.

Enjoy!