Thread: Checklist of tasks before going Live

Here are a dozen tasks you should consider before going "Live" with your website. These tasks will increase security and speed-up performance of your store.

Enable HTTP Compression
Optimize your bandwidth by GZipping static and dynamic content. See this blog for more information.


Add a P3P Privacy Policy & Compact Privacy Policy
Your sites' cookie can be blocked if your site doesn't have a P3P Privacy Policy. See this blog for more informaation.


Add an SSL Certificate
Customers look for the "closed lock" on your site when they want to checkout. A SSL Certificate is not only good business, for many Gateways it's required. The brand of certificate rarely matters anymore, so don't get talked into a $300/yr certificate when a $30 one will do the same thing.


Turn off Debug Mode
Edit your web.config file, and search for "debug". Make sure you set it to false (debug="false"). This will improve your website load times, and overall performance.


Rename Admin folder
"Admin" is easy to guess, so rename your Administration site. Then set the AdminDir AppConfig to the name of the new folder, so the store will know where to find it.


Lock-down your Administration site
Require a Windows Authenticated login for your admin folder. You can request this via your hosting company.


Re-compress product images
You can maximize your bandwidth, and even double your throughput by heavily compressing your product images. This blog has more information.


Set-up redirects for non-www requests
If you want to make sure *all* requests go to your www-site instead of your non-www site, setup a redirect in IIS. Here's how.


Review robots.txt
Make sure that you're not excessively-blocking search engine spiders. Consider the images folder... do you want your product images to be searchable? Have you added any custom pages that you don't want indexed?


Generate MachineKeys
Open the web.config file, and search for "MachineKey". Every site should have a unique set of validation and decryption keys. You can generate your own here.


Set a memory limit for your AppPool
Here's a good whitepaper (somewhat dated, but still accurate) on how to configure the AppPool for your web application.


Remove unused files from the site
Any files that your site doesn't use should be removed for your site (don't delete the file, just move it off the site in case you need it later). After removing any file, be sure to test your site to ensure you didn't break any functionality. Here's a list of files that are often removed:

ajaxPricing.aspx
ajaxShipping.aspx
auctioncheckout.aspx
authnetpost.aspx
bestsellers.aspx
cardinalauth.aspx
cardinalecheckauth.aspx
cardinalecheckform.aspx
cardinalechecknotify.aspx
cardinalecheck_process.aspx
cardinalform.aspx
cardinal_process.aspx
clickout.aspx
internationalcheckout.aspx
lat_account.aspx
lat_driver.aspx
lat_getlinking.aspx
lat_signin.aspx
lat_signout.aspx
lat_signup.aspx
nxfeed.aspx
ogone_postsale.aspx
ogone_return.aspx
paypalcancel.aspx
paypalexpressok.aspx
paypalnotification.aspx
paypalok.aspx
paypalok.aspx.cs
recentadditions.aspx
recentcomments.aspx
requestcatalog.aspx
scriptedrecurringimport.aspx
searchnx.aspx
secureauth.aspx
secureauthhsbc.aspx
secureform.aspx
secureformhsbc.aspx
secureprocess.aspx
secureprocesshsbc.aspx
sendform.aspx
staff.aspx
twocheckout_return.aspx
worldpayreturn.aspx

Set a custom error page and enable custom errors

In the web.config file there is a "customErrors" element. When you are convinced that your site is working properly you should set customErrors to On and create a static .htm page to be shown to your customers when an error occurs on the site. This will A) prevent your customers from seeing an ugly .NET exception if an error does occur, and B) will prevent your site from disclosing potentially sensitive information about your hosting environment such as the database name (in the case of a SQL error) or disk path of your site.

Hopefully, your site will become better performing and be more secure by performing these 13 simple tasks.


Note By Dan: I added custom errors to Jon's list. This is an important, but often missed step when going live.

Does HTTP compression really apply? All the product pages on the storefront are dynamically generated

Absolutely! The output of an aspx page can be compressed just like any other page. Markup, javascripts, and CSS can all be GZipped and cached by the server before being delivered.

Jon said:
Turn off Debug Mode
Edit your web.config file, and search for "debug". Make sure you set it to false (debug="false"). This will improve your website load times, and overall performance./quote

Do we turn BOTH debug settings to false??

there is two:
Set compilation debug="false" to enable ASPX debugging.
Set compilation debug="false" to insert debugging symbols...

false for both?

Thanks

Ho hum

http://validator.w3.org/p3p/20020128...refront.com%2F

This list is really really useful thanks. I noticed that the P3P blog entry talks about using IIS or an HTTP handler to set your policy but you can also do it from source HttpContext.Current.Response.AddHeader or use a link tag <link rel="P3Pv1" href="some uri">. I'm not sure about the browser support for the latter method.

See http://www.w3.org/P3P/validator/20020128/document

Rob

Set compilation debug="false" to enable ASPX debugging.
Set compilation debug="false" to insert debugging symbols...

Actually, setting compilation debug="false" disables debugging symbols, but yes, they should be set to false for live sites. This can have a significant performance impact.

Another important step:

Set a custom error page and enable custom errors

In the web.config file there is a "customErrors" element. When you are convinced that your site is working properly you should set customErrors to On and create a static .htm page to be shown to your customers when an error occurs on the site. This will A) prevent your customers from seeing an ugly .NET exception if an error does occur, and B) will prevent your site from disclosing potentially sensitive information about your hosting environment such as the database name (in the case of a SQL error) or disk path of your site.

@estore: There should be one line that looks like this:
<compilation debug="false" defaultLanguage="c#">

If debug="true", ASPX debugging is enabled by inserting debugging symbols into the compiled page. It should be "false" once you go Live.

@kentrob: There are two types of Policies, the Policy contained in XML files in your "P3P" folder, and the Compact Policy, which is a string of letter combinations.

The XML files are used to generate the "Privacy Report" in IE (View > Web Page Privacy Policy). I think the Compact Policy (the string of letters) is used to decide whether to accept the cookie under High Privacy.

I use both types of Policies, and I insert the Compact Policy into the Header using IIS Manager (website > right-click Properties > HTTP Headers tab > Custom HTTP Headers). This seems like the quickest method to me.

RE: Your validator link. I have no input into the design of that site That's all the higher-ups.

Okay. I think you can also add the reference to the policy file programmatically and with a link, which is useful for people who don't get access to IIS on their hosted servers.

Rob

Thanks I got the web.config file changed.

Jon wrote:
Rename Admin folder
"Admin" is easy to guess, so rename your Administration site. Then set the AdminDir AppConfig to the name of the new folder, so the store will know where to find it.


Jon or Dan
I had to have my host change my Admin name folder because I did not have write permissions. My store works fine BUT my question is,
in my folder there is now a Admin folder (the default) and the new folder (new admin folder) I changed the name to.

Is this normal?? Am I supposed to be seeing BOTH Admin and NEW Folder? I have never done this before so Im not sure the answer. Logically I would think that once the Admin folder was RENAMED the old Admin folder would not be there, but I do not know. So, Im asking.

Some hosts have an /admin folder for management of your site (hosting)....as long as that doesn't pull up your store administration site, you should be ok, as long as the host doesn't have any issues. If it pulls up your AspDotNetStorefront admin site, the folder rename was not done properly and must be addressed.

Thats exactly what I thought. I know what he did. He took and moved the Admin folder off the site from within ASPDNSF root and renamed it then uploaded it and left the Admin folder in place.

So, can I just delete the Admin folder from ASPDNSF root?

I had them install (so I thought) the dev-test ASPDNSF so that now that my store is live (in about 1/3 hour) I can use it to do testing etc and he copied my store and then just uploaded it as my testing store instead of installing it from out of the box.

Thanks for your help. Much appreciated.

Yes, that is what I woudl have suspected also.

Make sure AppConfig:AdminDir={nameofadmindir}

before you do all this of course. or the site won't know how to find it's own admin site.

ok thank you. Im doing a backup before I delete it.

Thanks a bunch

YES. thank you. back up EVERYTHING before making changes. (full db, and full website zip). You never ever know when you need that later. and it takes only a few minutes to do.

Is it a'ok to delete the language folders to?

Danish, Swedish, French, German, Finish and Norwegian...

Never "delete", just "move" off the site in case you find out you need it. As far as language folders, I'm not sure.

Certainly for UK sites accepting Maestro cards, you'd also want to make sure the credit card payment form is showing Start Date and Issue No

There's an AppConfig called ShowCardStartDateFields which needs to be set to True

https://support.aspdotnetstorefront....barticleid=252

If using Protx gateway, their simulator accepts Maestro payments without this set, but when you go live, Protx just declines the transaction without giving a reason.... took me a while to find out why. Hopefully this post will save someone else the same grief!

Thanks for the NICE post Jon.

With regards the Machine key .. if am on a dedicated server would i need to Generate a MachineKeys?

Yes, every web application needs a unique set of MachineKeys.

Ours is set to 'AutoGenerate'. Is this bad? Should that be hard-coded?

It's not optimal. You don't want your server to generate a new set of keys while you have shoppers on your site. They will all receive "Invalid ViewState" errors, and have to start a new session (re-login).

Is it safe to do this now since the site has been up for so long?

Jon/ASPDNSF Tech Support.

First of all, thanks for this post. I've been able to knock out most (1/2) of the items on the list except the following:
1) Enable HTTp Compression
2) P3P Privacy Policy
3) Re-compress product images (haven't looked at this one yet, 2 b honest)
4) Set-up redirects for non-www requests
5) Review robots.txt (not really sure what I need to do here)
6) set memory limit for AppPool (haven't looked at this one yet, 2 b honest)

It looks like most of the items mentioned above require that we have access to IIS, correct?

If so, I'm using an ISP (Applied Innovations) and have no way of administering IIS, how can I implement these items. In your experience, do you know if AppliedI is willing to handle these requests. Is it really worth the efffort?

For instance;
1) Enable HTTP Compression
- From the IIS snap-in, right-click on the Web Sites node and click on Properties
- Select the Service tab - Enable Compress application files
- Enable Compress static files
- Change Temporary Directory to the folder that you created above, or leave it at it's default
- Set the max size of the temp folder to something that the hard drive can handle. i.e. 1000.
- Save and close the Web Site Properties dialog

Note: The temporary compress directory is only used for static pages. Dynamic pages aren't saved to disk and are recreated every time so there is some CPU overhead used on every page request for dynamic content.

Create a Web Service Extension (WSE) etc, etc, etc



2) P3P Privacy Policy
Use Internet Services Manager within MMC to configure Microsoft Internet Information Services (IIS) to set custom header properties to pages, virtual directories, or entire Web sites. To enable P3P custom headers using Internet Services Manager to configure IIS. (NOTE: If you don't have access to your IIS instance or your ISP doesn't want to help you out, you can also add these HTTP Headers programmatically using an HttpModule.)

4) Set-up redirects for non-www requests
Under your parent domain in IIS, create another website with example.com as the host name and then right click on it> select properties> Select Directory> A redirection to a URL> enter http://www.example.com$S$Q> Select "Exact URL">Select "A permanent redirection"> click ok



My main question is; Can AppliedI, do this for me? or, because AppliedI was recommended to us for ASPDNSF, are they already doing these things?

Please let me know ASAP because I'm having my customer go live tonight (they are switching their live domain www.guitarhotline.com to the AppliedI hosting platform Nameservers).

Thanks

Jeff O'Connell
jboconne@iupui.edu

Paul Kimmel's article "De-Sludging ASP.NET Pages with PageAdapter" is a simple method for storing viewstate on the server if you can afford the memory. This will decrease the size of your pages and thus increase the speed at which they are served.

Originally Posted by barney

Jon/ASPDNSF Tech Support.

My main question is; Can AppliedI, do this for me? or, because AppliedI was recommended to us for ASPDNSF, are they already doing these things?

Please let me know ASAP because I'm having my customer go live tonight (they are switching their live domain www.guitarhotline.com to the AppliedI hosting platform Nameservers).

Thanks

Jeff O'Connell
jboconne@iupui.edu

did you find out if appliedi does this automatically .. we also use them for hosting aspdnsf ...?

Originally Posted by ASPDNSF Staff - Jon

Set a custom error page and enable custom errors

In the web.config file there is a "customErrors" element. When you are convinced that your site is working properly you should set customErrors to On and create a static .htm page to be shown to your customers when an error occurs on the site. This will A) prevent your customers from seeing an ugly .NET exception if an error does occur, and B) will prevent your site from disclosing potentially sensitive information about your hosting environment such as the database name (in the case of a SQL error) or disk path of your site.

Hopefully, your site will become better performing and be more secure by performing these 13 simple tasks.


Note By Dan: I added custom errors to Jon's list. This is an important, but often missed step when going live.

i set the custom errors element to on ... but exactly where to put the .htm page and how to i direct my site to point to that page when there is an error... ?

thanks in advance.

chris

i found the answer to my question ..

http://support.aspdotnetstorefront.c...barticleid=277

Where are the web.config files which you noted to change the debug mode in. I can't find this parameter.

web.config is at the root folder of the application