Validatation for Custom User Controls

Recently I stumbled across the problem of needing to validate user input supplied to a Custom User Control.  Usually validation is simply the case of dragging one of the excellent validation controls onto the page and pointing it towards the control you wish to validate.

Custom User Control's however are a different story.  These are controls written by a developer to carry out a function which no other existing controls can.  As they have been written from the ground up, they cannot be simply associated to a validation control without further work.

To allow a Custom User Control to be validated the first thing which is required is the addition of <ValidationPropertyAttribute("value")>.  This specifies the property which supplies the string to be validated, where "value" is the name of the property.

Secondly the ControlToValidate="" property of validation control on the page should be the ID of the user control, colon(:), then the ID of the control to which 'value' is associated.

For example I had a control named cboTask which had <ValidationPropertyAttribute("value")> defined within it where value was a property which returned the current value of a DropDownList (DropDownList1) which was contained within cboTask.  In order to validate that the user selected an option I used the RequiredFieldValidator with the ControlToValidate="cboTask:DropDownList1".


<ValidationPropertyAttribute("value")> _
Partial Public Class ctlDropDownList
    Inherits System.Web.UI.UserControl


 Public Property value() As String
        Get
            Return DropDownList1.SelectedValue.Trim()
        End Get
        Set(ByVal value As String)
            Dim llistitem As ListItem
            DropDownList1.ClearSelection()
            For Each llistitem In DropDownList1.Items
                If RTrim(llistitem.Value) = RTrim(value) Then
                    llistitem.Selected = True
                    Exit For
                End If
            Next
        End Set
    End Property

End Class


 <asp:RequiredFieldValidator ID="rfvTask"
       runat="server"
       ErrorMessage="Task cannot be blank"
       InitialValue=""
       ControlToValidate="cboTask:DropDownList1"
        ValidationGroup="page">*</asp:RequiredFieldValidator>




Doing this allows both client and server validation, and allows you to use the validation controls as you would with any of the existing .NET controls.

Preventing an error 403 ever reaching the client

I was put in the strange position of preventing an ASP.net web application sending an error HTTP 403 to the client.  This was following 'security recommendations from the experts' that an error 403 confirms to an attacker that they have identified a part of the file structure.

Anyway this is how I managed to do it:

Add an Application_Error method to Global.asax which directs the user to a known page:

protected void Application_Error(object sender, EventArgs e)

            {

           

                Response.Redirect("Default.aspx");

           

}

and configure IIS custom error page to direct to a non-existing page,  this will show in the logs so choose something like /AttemptToAccess403.aspx.

When the server encounters a 403 it will look up the non-existing page which will cause an error in the application.  This is caught via the Application_Error method and will direct the user to a valid page (Default.aspx).  To the user this is invisible, however the server has logged the attempt to access a directory structure (403) as an attempt to access page /AttemptToAccess403.aspx and an error 403 is never propogated to the client and hence satisfies the security requirement.

Headers returned to the client:

(before)

HTTP/1.x 301 Moved Permanently

HTTP/1.x 302 Found

(after)

HTTP/1.x 200 OK

HTTP/1.x 200 OK

As for the initial 'security' concern....

ASP Menu bug in IE8 and Chrome

Well it turns out there is a bug in the ASP Menu control that stops the dynamic part of the menu rendering when the user rolls their mouse over a static part of the menu.

It appears the problem is to do with the way the control checks if the browser has javascript enabled, and it decides both IE 8 and Chrome don't, hence nothing is shown to the user.

The only work arounds I've come across are:

• Don't use the thing
• Put IE8 into compatibility mode (or download this hotfix)
• Use this nasty hack around

Obviously we cannot expect our users to have to follow special procedures to view our site, and with the only other solution being a hack, we'd rather go with something else completely...

Regular Expressions are fun

I've finally made the effort to fully understand how to write my own regular expressions.  In the past I just had no idea what something as cryptic as ^.+[a-zA-Z][a-zA-Z]\d\d\d\d\d\d.+?.pdf|^.+\w+\.xml (I just wrote that) meant.

Plugging that into my application now means that it fully validates my input, and does it perfectly.  How did we manage before these things were invented?

Using the @MasterType directive instead of the @Page directive with MasterPageFile=""

Just a quick snippet for future use.  When referencing a master page within your aspx file its best to use the @MasterType directive rather than the MasterPageFile="" attribute of the @Page directive.  Doing so will allow strongly typed access to any methods you've put in the master page rather than having to do something ugly.  Example:

((DefaultLayout)this.Master).SetPageHeading("This heading is set from inside Default.aspx");

becomes:

Master.SetPageHeading("This heading is set from inside Default.aspx");

Much better dont you think?

Browser discrepancies, arghh!

Why oh why do browsers from different vendors (Internet Exlorer, Firefox, Chrome etc) STILL have problems agreeing on the correct way to display a web page and correctly interpret javascript?

The World Wide Web Consortium has been around for 15 years now and defines the standards required for web developers to follow (which I must say I attempt to do very carefully) only to find that most browsers out there don't (or even worse have their own interpretation of them).

The problem here is the W3C leaves it up to the software manufacturers in order to become 'compliant', which doesn't mean much, as there are different standards of compliance, huh?

Microsoft's latest version of Internet Explorer claims it is "standards compliant" and has been riled all over the internet forums for breaking existing websites. Which I think is a very positive move as now these websites must also begin to follow standards or start losing traffic.

I think the only way this can be tackled would a scheme which checks new web browser software prior to market for compliance, and only if it passes 100% of tests can it legally be called a browser. Such a scheme could work in the same way that SSL certificates are issued, and would work something like this:

• Software is submitted to an independent authority which performs tests on the browser for compliance with current standards
• Following a successful result a certificate is issued based on a signature of the software, and is unique to that software
• In order resolve domain names this certificate must be included in DNS requests, failure of which would mean the request is ignored

Assuming this is possible would mean that non-compliant browsers would be less convenient to use for end users (who wants to type in IPs each time they want to visit a page?) and would result in loss of custom, forcing them elsewhere.

On a side note the latest version of outlook express actually uses the Word (yes Word) to render embedded HTML, surely this is a joke Microsoft?

Why I hate the bank card readers

All the major banks are now supplying the darned card readers to be used for online transactions.

If you don't know what I mean they're the little "calculator like" devices which you insert your debit card (and pin) to allow yourself to be authenticated via online banking.

However (like all security) there are downsides:

• You have to carry one everywhere you do your online banking
• For some reason most institutions lock them to only work with their cards (so you cannot simply borrow one from someone)

Most people mis-understand how these devices work, the clue is in the name, they are a reader, they don't have any logic on-board regarding anything financial. The processing all happens within the chip itself on the card, the readers are simply a means of communicating with your card.

Regarding having to use one for each institution would be very understandable if each used their own algorithms for card transactions, but this would be both a massive overhead and simply isn't the way its done (do they have different card readers for each bank in the shops?). Instead a marker is set on the card detailing the banks 5 digit number. The readers must simply compare this to a pre-set value and if not identical "Wrong Card", god dam!

Forcing most people to have to carry this stupid things around with them.

Regarding security they can actually make it worse. Picture this. Dark alley late at night. Thieves mug you, get your card, and demand your pin. It can be checked on the spot, without the thieves having to risk marching you to the nearest cash machine. This is stupid that these things actually issue "wrong pin, try again". A better way would to be simply issue the authentication codes anyway, which would of course be wrong had the pin being incorrect.

Nevermind, maybe the banks will catch up with technology one day...

Shame on you banks for locking down on internet banking when the whole ethos is around making it more convenient for their customers.