StripesAndPolkaDots.com just launched a site redesign on BV Commerce 5 with Global Web Solutions (GlobalWeb.net) and WebWorxInc.com in Richmond, VA. Stripes & Polka Dots specializes in unique gifts, necessities and “just gotta haves.”

If you’re looking for Personalized Bmbroidered Gift Items, Blankets, Burp Cloths & Bibs, Sippy Cups, Snack Cups, Bow Holders, Wall Letters, Koozies, Travel Tumblers,
Personalized Stationery, Badge Reels, Laptop Sleeves, Checkbook Covers, Key Fobs, Luggage Tags, Headbands, and much, much more visit StripesAndPolkaDots.com today.

It's been a while since my last blog post. Things have been very busy at BV Software and I'm excited about what we have planned for 2010.

•  BV Commerce 5.7 is currently finishing PCI compliance testing. I had hoped it would be ready before the end of the year but it will most likely be January before everything is officially certified. This is a free service update for anyone with the maintenance plan.
•  BV Commerce 6 is nearing its first beta version and I'm excited to be able to start to release some details. The entire core source code has been ported to C# and all future development will be in C#. That probably doesn't mean much to merchants but developers will want to be prepared. One of the main reasons for this is that c# is rapidly becoming the preferred .net language (other than dynamic languages like f#). The second reason is that Express versions of Visual Studio are single language only and when we standardize on C#, developers will be able to compile all projects using the free software.
• Originally, BV Commerce 6 was using ASP.NET MVC for the store pages but we kept webforms pages around. As development has progressed, webforms 4.0 is proving to be just as effective for most pages and much faster to work with since BV Commerce 5 is based on webforms and we have less to rewrite/test. There may be some MVC pages in BV Commerce 6 but if you're used to working with BV Commerce 5 you won't have to learn a whole new development system.
• BV Commerce 6 is on track for a spring 2010 release. It will be a free upgrade for all maintenance plan customers. 
• I'm not quite ready to release feature changes for BV Commerce 6 but the admin pages are getting streamlined and there are some nice new search features for the store side.
• The BV Commerce user conference planned for early 2010 has been postponed. The economic environment has made it difficult for many people to get travel budgets and I'm looking into the possibility of a webinar/virtual conference or scheduling an in-person conference for later in 2010 as the financial world improves.

I'm working on BV Transfer today. It's a new import/export tool that's designed to be a lot more flexible than the current tools. Right now, there is a flat file import/export tool, a StoreFront import tool, a BVC 2004 Migration tool and of course web service import/export. They all do very similar things and there is a lot of duplicate code. The bad part is that even with all of those tools you still can't do some simple things like a BV 5 to BV 5 transfer without extra steps in the middle.

The new BV Transfer tool is taking a modular approach. There is a universal "product" class and there will be providers that can read and write this format. The idea is that I could create an XML provider to read/write a specific type of XML file. Then, someone else could create a Mail Order Manager provider. In that example, I could transfer products directly from Mail Order Manager to an XML file. Write a provider for BV Commerce 5 and now you can import from XML into BV Commerce and then export to Mail Order Manager. 

My goal is that the univeral format in the middle will help protect against some version changes. There could be a BV Commerce 5.3 provider and a 5.5 provider so that the tool could be used to migrate from an older store to a new development store on the latest service packs. 

I don't know when it will be ready. Just wanted everyone to know that it's in development.

There are thousands of unused feature votes right now. If you signed up for the maintenance plan you've got votes. Use them now because at the end of the week I'll be tallying up the winning features. Those features will be added to BV Commerce within a year. If you don't use your votes your voice won't be heard. The top feature at the moment only has 50 votes so your votes still matter.

Vote at https://accounts.bvcommerce.com/

For the last 8 years I have provided FREE service packs and updates for each version of BV Commerce. During that time BV Commerce has grown in size and features. It integrates with many outside systems like UPS, shippers, Authorize.net, credit card gateways, tax services, QuickBooks and more. The effort required to keep up with these features has grown exponentially.

In order to keep up with integrations and add new features to BV Commerce I have introduced an annual maintenance plan. The plan will ensure that I can maintain BV Commerce going forward, complete PCI Certification and add new features for FREE for those customers subscribing to the maintenance plan.

There is an interesting discussion going on in the forums about URL formats for Search Engine Optimization. We're talking about balancing the application's need to effeciently parse out product information like SKU or ID number with the merchant's desire for the cleanest URL format that has the most information for Search Engine Optimization.

What do you think about URL formats? Chime in on the forums.

BV Commerce 5 offers "anonymous" checkout. I'm not sure what to call the feature other than "anonymous." Maybe "guest" checkout is more appropriate because you still collect the name and address of the customers. The feature was designed so that customers were not required to create an account during the checkout process.

Jared M. Spool of User Interface Engineering recently posted an article explaining that making it clear that registration was not required during checkout boosted one of their client's web sales by 300 million dollars. What UIE did was to change the text of a button from "Register" to "Continue" which was seen as less intrusive by shoppers during the checkout process. A simple change that had the effect of making the login step optional.

There are plenty of reasons to require customers to register during checkout. On the BV Software Store we require customers to create an account because we sell electronic goods and have found that when customers explicitly create their own account it is easier for them to remember later. This saves us some support requests about usernames and passwords. Also, our audience tends to be fairly technical and isn't afraid of creating accounts.

If your store requires registration during checkout think carefully about exactly why you require it. You may be losing a significant number of sales because of it.

If you need to allow users to enter Html for display on your web site or application you're asking for trouble in the form of a Cross Site Scripting (XSS) attack. This attack is pretty simple. Imagine that you have a text input field and then you display the value that was input back to the user. For example, an error message might return the value the user entered. The user enters something like <script>javascript:alert('hello, from a hacker');</script> and suddenly they can control javascript coming from your server.

The first level of response is to HtmlEncode anything that is input from the user. This is what many of the built-in ASP.NET controls do for you and something that you should alway do in ASP.NET MVC.

But, when you encode everything the user enters you can't let the user create a bold tag, <b>Name</b> , which is perfectly safe. How do you allow safe html to get posted without encoding while making sure everything else is safe?

One approach taken by most bulletin boards is to adopt a special language, like BBCode, which is a limited grammar of acceptable tags. BBCode is used by our DotNetBB software right now and looks something like this:

[b]This is bold[/b]

[url=http://www.bvsoftware.com]Link to BV Software[/url]

This type of language works well but it isn't good enough in my opinion. Why should users need to learn a new language instead of html which is a standard already. Furthermore, if I'm a designer and I'm working on a nicely formatted post in DreamWeaver I have to convert it from Html to BBCode before posting.

So, I decided to build an Html sanitizer that will allow a safe subset of code to be posted while encoding everything else. I'm not the first person to try this and I looked over a lot of community code for ideas. What I found was that most of the scrubbers used Regular Expressions to match potentially dangerous scripts and then tried to remove or encode them. Here's one from Jeff Atwood of Coding Horror and here's one by Rob Conery of SubSonic Fame.

I have a love/hat relationship with regular expressions. They can be huge time savers and can present a simple solution to complex problems. They can also end up many lines long and so un-readable that you never have any hope of debugging the code. The regular expressions I found in the other scrubber code were just that. Long, complicated and not error proof at all.

Here are some examples that you can use to test for XSS attacks. When you see the huge variety of attacks possible you'll realize that a simple regular expression isn't going to cut it. If you look at Rob's Code. You'll notice that he took a different approach. His choice was to "white list" the safe tags and encode everything else.

I also took the "white list" approach but after reviewing possible attacks decided that I needed an extra step. Instead of just allowing safe tags through, I would parse the tags and rewrite the safe ones with a subset of tag attributes that are also safe or easy to check.

Step 1: Tokenize the text to find all of the Html tags. This was a simple matter of splitting the string on the "<" character. Every opening and closing tag needs to start with this.

Step 2: Walk through the tokens and do a basic parser routine. When we're not parsing a tag, HtmlEncode everything else. When we are parsing a tag, get the start tag.

Step 3: When parsing the start tag check to see if it's an allowed tag. If not, HtmlEncode it. If it is, check to see if it's a self closing tag like <br/>. If it's self closing, rewrite it in a safe manner. If not, keep reading tokens until you find the end.

Step 4: If you haven't found a valid tag that is closed just HtmlEncode everything you have and dump it.

Step 5: Rewriting tags. When you do find a valid tag (self closed or not). Parse out the name and attributes from the tag. Look over the attributes in a name/value list and only rewrite out the attributes you've selected as safe.

Step 6: Some attributes, like SRC and HREF require extra attention. They are vulnerable to javascript: and vbscript: tags in the attribute value.

I've taken all of the examples from an XSS sample site and my code has safely taken care of everything I can throw at it. I don't want to get cocky about it because someone could find an exploit tomorrow. 

Some other things to note:

I had to choose a subset of html that I thought was safe an appropriate for users to enter:b,i,u,em,strong,h1,h2,h3,h4,h5,h6,div,span,p,blockquote,ol,ul,li,address,strike,a,img,sup,sub and hr

I had to be VERY strict on the formatting I allowed for html. All tags must be lower case. All tags must be closed. All tag attributes must be wrapped in double quotes. etc. This strict xhtml formatting makes it easier to parse out the safe tags and is generally a good idea. Less sophisticated users may not understand why the Html of their Word doc didn't come out exactly as they expected but I'm okay with that.

It's not a simple problem but I think my solution is working well so far. This code will be included in the new version of DotNetBB and some other projects I'm working on.

Is this something that you need for your projects? Should we consider wrapping it into a nice library at an attractive price?

I announced at the end of 2008 that the price of BV Commerce 5 is returning to $999 per store as it was in 2007. I didn't give people enough time to react so I'm delaying the price change until Feb 1st, 2009. If you or your customers are considering a purchase of BV Commerce 5 it won't be cheaper than it is now at $499 per store.