Tuesday, March 31, 2009

Performing GET with secure data

You shouldnt full stop! Even if the GET is performed over HTTPS, the complete GET URL with associated query string parameters are logged by the web server (in my case IIS logs) but would assume that Apache and other popular/capable web servers would do the same! Any web intermediaries would also log the data.

If you need to get secure data passed from the browser where the current domain is HTTPS to a different HTTPS domain you cannot perform the following:
1. Perform a POST (see previous post)
2. Perform a GET (cant as web servers log the data - not advised)

So what is the solution?
Really, the only solution is to perform a server to server call. Rather than calling direct from the browser, pass the secure data to the website/applications associated web server and perform a server to server call from there!

Posting across secure domains

Came across this issue in the last few days. If your browser is at https://securedomain1/... and you need to POST to https://securedomain2/..., you cannot trust this as IE and FF browsers later versions (and I would assume Opera + other browsers also) detect this and notify the user who is given the option to manually move on or not!

This is just a point of note. Usually one should aspire to design a web application where posting from one secure domain to another does not occur. Typically in an e-business website, the payment detail page will be secure and often hosted by a third party. Hence the rest of the website is non-secure as it is not required. You don't want your website to be over HTTPS and then having to redirect to a third party in a different secure domain over HTTPS.

Tuesday, March 24, 2009

Building domain specific languages in Boo

Started reading building domain specific languages in Boo ref: http://www.amazon.com/Building-Domain-Specific-Languages-Boo/dp/1933988606

Want to learn how to write DSLs, when to write them etc. Would be more in favour of writing using a language like Ruby but we will see how Boo goes I suppose. Will post on this in the future.

Monday, March 23, 2009

QUnit for javascript unit testing - my recommendations

QUnit - the unit testing test runner used for jQuery has turned out to be a valuable investment and javascript related bugs have been reduced considerably in a project I have been working on primarily due to its adoption.

I am not going to explain how to integrate QUnit tests, to learn how to do so please refer to http://docs.jquery.com/QUnit

The following are points of note in relation to how I have applied QUnit:

1. Have a 1-1 relationship between your js file and the QUnit htm file i.e. example.js should have a corresponding example.htm file

2. As all tests for a particular js file are in a single test QUnit .htm file, I tend to only use a single module. Using the module, you can perform setup and teardown functionality (which gets executed for every QUnit test)


module("sample module",
{
setup: function()
{
//do setup stuff...
}
teardown: function()
{
//do teardown stuff...
}
});

test("first test with setup")
{
// set conditions
$("#control1").val("testval");

// execute javascript function
sampleFunction();

// assert
assertTrue($("#control2").val(), 10);
};


3. All HTML controls that are used by the javascript you are testing need to be replicated in the .htm file.

4. All tests are similar to above in format i.e. set, execute and assert

The only problem I currently have is integrating QUnit tests into automated builds - using WatiN! - Will do future post when this issue is resolved