Creating a Cancel Button to Go Back

Many of you may be familiar with the need to add a Cancel button on a form or other page.

I ran to an interesting development though when all I wanted it to to was return to the previous page.... the previous page, as defined by the JavaScript history cache, is not what you may have expected. It seems that EVERY postback is stored in the browser history cache and going back like this...
<input class="button_red" onclick="window.history.go(-1);" value="Cancel" type="button">
may not always work. Sigh.

Well, never fear for I have found a solution that works quite well. It starts by modifying the HTML control a little first:
<input runat="server" id="btnCancel" name="btnCancel" class="button_red" value="Cancel" type="button">
You will notice that it is setup to runat the server, which will allow me to access it from the code behind file. Also, I have removed the onClick event since I plan to add it dynamically instead.

Next, if VS.Net is as unkind to you as to me, you will need to add the following object declaration:
protected System.Web.UI.HtmlControls.HtmlInputButton btnCancel;

Once you can access it, the next trick up our sleeves is to use the ViewState to track how many times you have accessed this page. For those who are unfamiliar, the ViewState lets you store values in it, much like a Session, and embeds them into the form.
try
{
ViewState["history"] = Convert.ToString(Convert.ToInt32(ViewState["history"].ToString()) + 1);
}
catch
{
ViewState["history"] = "1";
}

You will notice that I am cheating here by using a Try.. Catch to validate whether this is our first visit. If it is our first visit, the ViewState key will not exist and cause an Exception, which in turn sets the key to a number one.

The final bit of code we need adds the onClick event to our HTML button:
btnCancel.Attributes.Add("onClick", "window.history.go(-" + ViewState["history"] + ");");

There you go! Anyone have any improvements? Comments?

Time To Show It Off

I hope to have some new improvements for my blog and my side consulting business (Full Force Technologies) by this weekend, or certainly by next week. What type of improvements? CODE!

Yep, that's right. It is time to put my talent where my talk is. I will be making some changes to my company site to accomodate two things: 1) that it is a single owner business 2) Demo's and code samples.

It should be interesting to see how that works out. My first order of business is showing off the rotating session key functionality and seeing if someone out there can poke holes in it. We'll see.

Blogging on the Job

While it still seems to be an IT phenomenon, blogging on the job is becoming very popular. I just finished reading an article from the San Francisco Chronicle that was interesting.

While I don't blog about the company I work for, or even my own side business, it isn't because it wouldn't be interesting.... I just prefer to talk tech and both of these companies are so small no one has heard of them.

Conventional wisdom says that someone will mess it up for others, but the steps these companies have taken could actually work and conteract the stupid among us.

Only time will tell.

Somehow I Thought I Would Score Higher

I probably scored lower since I am actually married... hehe.

Session State and Security

Session state control is a tough thing to handle. If you are in a web farm environment it gets even tougher. What are the options?

1. Use an IIS Session State server
2. Don't use web farms and use the Session object
3. Manage session state manually by passing a key

It is option number three that I want to talk about. Option 2 doesn't work if you have to build reliability into your system and Option 1 only works if you have the extra money.

Session Key Management
So, how would you do this? Most developers will generate a unique key and pass it back and forth, or maybe even use the ViewState. I like to use both.

When trying to use manual session keys, I will generate the key and then append it to all internal links plus add it to the ViewState for post-backs. This is that hard, just have an extra function that is called last iterate and append the data to all hyperlink objects (doesn't work it you use HTML href's). But is this secure?

I came up with, IMHO, a method for securing the session key itself. Stay with me, it gets interesting. First off, you will need the following data:

• Browser User Agent (ServerVariables value)
• First three octets of client IP address (Parse the ServerVariables value)
• Unique user number (Probably from a database or server side xml file)
• Last accessed timestamp

Here is how a typical first interaction will transpire with those values:

1. Upon first access, update last accessed timestamp
2. Take all four values and append into one large string
3. Use a hashing algorithm (I like SHA256) and hash the string
4. Store the returned value (now your session key) and pass to client in ViewState and appended to links

Now that we have our key, most people would stop here and just pass it back and forth, validating it against the stored value in the database.... but that isn't secure. Nope, if all you did was pass it around than ANYBODY could snatch it and use it. To be secure we need to follow a second set of steps whenever a return user accesses our site:

1. Take the passed in session key and validate it matches a current one in the database. Some developers also enforce a "session" timeout and check the last accessed time and log them out if it exceeds the system timeout. For our purposes, we will assume they have not reached system timeout.
2. Now that it is valid, we ditch the entire key and RECREATE IT AS WE DID BEFORE. Read that again... we get all four of the ORIGINAL values, append them, and hash them. Then we validate against the database to see if they still match. This is the security we are looking for.
   
3. Now that we are positive the keys match, we ditch the entire key again, update the last accessed timestamp, and create a new key and deliver it to the client the same way we did with the initial key.

Interesting? I have found that it stops all of the session abuse I have witnessed in the past. Anybody see a vulnerability with this scheme? Thoughts?

Wanna Stop Phishers? Join the Club

I just read a facinating article by Robert X. Cringley. I have been reading his work for years, and those of you who read InfoWorld will recognize the name.

Awhile back he left InfoWorld (even though there is a column with his name still being written) and his columns are hosted at PBS.org now.

Anyway, the article I just read was regarding how we can all work together to stop Phishers. I think Cringley is right on target and gets an A+. I almost can't wait to get an email from a Phisher now.

Check out his article here.

Javascript element.focus() and ASP.NET

I'm not sure how many of you have run into this problem, but here it is in a nutshell.

Let's say you want to have a form load (web page) but want to specify which textbox, or other form element, has the focus. How would you do that from the code behind file?

You can't.

I know, how dumb. To make matters worse, it isn't like you can just create a javascript block and say:

document.[formname].[elementname].focus()

Why not? Because .NET will change the reported name of your form element in many cases.... such as when you use User Controls. Yep, that's right. Not only does it rename it, but it gives it a name like ctl0_[yourname]. Yuck.

So, what is the solution? Since I just had to work this out, here is what I came up with. [Be aware that I use the QueryString or Form to pass the element to focus on. This could be easily changed to using control properties, I just didn't need to]:

On the parent (first) page, add a javascript block like this:

SetFocus()
{
var elementFocus = "<%=elementFocus%>";
if (elementFocus != "")
{
document.Form1.elementFocus.focus();
document.Form1.elementFocus.setSelectionStart(0,0); //my pref
}
}

In the parent code behind, create a public string named elementFocus and set it to the Querystring and/or the Form objects value for the focus key.

Now, on the page WITH the form element you wish to focus, which may be the parent or an added user control, create a variable that you assign the all important property to.... ClientId. ClientId is the actual name that ASP.NET plans to name your form field based on what it current knows is being rendered. By grabbing this value and passing it via the QueryString/Form/Property value, you now know the name to set focus to.

That's it. If you want a more complete code sample, just let me know.

The under-used IFRAME tag

How many of you out there use the IFRAME tag? Do you even know what it is?

If you have never looked at it before, the first thing you need to check out is the W3C specification. The IFRAME, or Inline Frame, allows you to put a frame in the middle of the page!

How is this useful? For those of you who like graphics ladden websites, this allows a graphical border the completely surrounds your frame. The frame itself will have a scroll bar, just like other frames.

I have found it useful lately in avoiding Event Handler hell. I have a page with a user control, that has a second imbedded control inside the first and one more inside of that. It makes sense in how the data relates and the UI needs to interact with the data, but it means that button clicks must have Events that are captured at the higher level pages and passed down to the last embedded control. I have still not found an EASY way to do this, so my answer was an Inline Frame.

By moving my code into a seperate frame, poof, new same level Event Handlers for all interactions I need to make. Ah, the blissfulness it has brought is worth it... plus it looks good.

I'm curious how often this frame type is used, and how others have utilized it.

More to this than .NET

 

Interestingly enough, I am a Star Wars fanatic.  No, not the kind that makes his own costume and camps outside the theater... but I do have to play all of the PC games LucasArts produces and read all of the fiction I can find.

 

Why is this important?  It isn't really, but since I have recently started this Blog I thought I would try to lay a foundation of my personality as well as my technical skills.  It is amazing what interests people.

Web User Control Hell

Web user controls.... an innovation that can make or break a good ASP.NET object oriented design.

The problem is, once you start modularizing your controls, and embedding them within each other, the event model breaks down. I guess breaks down is too soft, is just doesn't work. The answer? You have to write event handlers at higher levels that will trickle back down and trigger the correct event in the embedded control. Sheesh. It is easier to revert to classic ASP style solutions that to do this.

Anyone out there have a tried and true method for working this issue?

All about the Destination

Why be a blogger?

Well, in my case I am both a Star Wars fanatic (just ask my wife) and a lover of web development discussions. How do they relate? Hmm.... I'm not sure that they do, but Star Wars has been such a presence in my life that I had to include it. Stick around and you'll understand.

As for web development... I am a .NET junkie to be sure, but I also appreciate the finer points of (X)HTML, CSS, Javascript and whatever else they will come up with to help me make good looking, but extremely functional websites. My current tinkering is with C#, but I grew up as a Delphi/VB programmer. Yeah, I know it isn't C or JAVA, but it does the job and it does it well. This blog is partly about how to make it work though.

Anyway, this is the start... let's see where it goes.