When mock-ups and screenshots fail to deliver the idea that you are trying to convey, a prototype can deliver a strong impact. But why should you prototype with GreaseMonkey when you can check out code from source control and mock a web page with a few shabbily scribbled lines of javascript ?

I often find myself comparing GreaseMoney with the Netbeans swing builder for thick clients. Its great because you can deliver a quick UI without worrying about the underlying functionality. But where GreaseMoney differentiates itself is in its ability to mock a live web page. By live I mean one that is already deployed on production. Never underestimate the impact of mocking a feature on a live website. Changing the innerHTML of a few HTML elements and hacking out some JS can get you quick results.

How an idea is presented to a person that might green-light it is pretty critical.From my experience, here is how it usually plays out

Of course, I am not trying to suggest that all ideas that you mock on a screen-scrapped live web site will kick off. An idea is great only when your potential users realize its significance and importance. The way you can get them excited about it, is to actually show them what it could look like. Once they are wowed, they will be eating out of your hand.

Be wary of the risk of getting folks too excited. Explain carefully that you are screen scrapping a page before you present it. The last thing you want is a customer thinking that you already implemented an idea

If you have never used GreaseMonkey before, the hello world tutorial is a great place to start. As you get your way around the simple stuff, you will eventually perform relatively complex operations like changing HTML content, setting timers, making ajax calls. Some of those steps will not work due to limitations in the way GreaseMonkey works. Which is when this common pitfalls page will be of great help.

Good luck mocking your web page.

There are times when you work with SSL traffic. Your website might be protected with a certificate so that traffic between you and the client is secure. At times like this, being a developer is troublesome. Browser cache settings need to be analyzed by looking at the HTTP headers. Encoding / Content type may need to be analyzed to ensure that a particular page is displayed correctly. These things cannot be looked into if the traffic is secure. There are situations under which the environment is secure but you must still sniff the data. So how do you manage this ?

Tools like Charles (A debugging proxy) help you do this. Charles allows you to proxy to a secure connection over a protocol like HTTPS and still read the traffic. So how does it do this ? Lets have a look.

Your environment probably has a self signed certificate like the one issued below, using keytool.

keytool -genkey -keyalg RSA -keysize 1024 -alias example.com -keystore mystore.ks -validity 9999
 
keytool -list -keystore ./mystore.ks -v
 
Enter keystore password:  changeit
 
Keystore type: jks
Keystore provider: SUN
 
Your keystore contains 1 entry
 
Alias name: example.com
Creation date: Dec 21, 2009
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=www.org.com, OU=Org, O=SomeCompany, L=Somewhere, ST=Someplace, C=US
Issuer: CN=www.org.com, OU=Org, O=SomeCompany, L=Somewhere, ST=Someplace, C=US
Serial number: 4b2ef9e0
Valid from: Mon Dec 21 10:00:24 GMT+05:30 2009 until: Thu May 07 10:00:24 GMT+05:30 2037
Certificate fingerprints:
MD5:  XX:XX:XX...
SHA1: XX:XX:XX...
 
*******************************************
*******************************************

When a certificate like this one is presented to a web browser, it will look like so. Let’s extract the certificate and open it up.

keytool -export -keystore ./mystore.ks -file ./testtex.crt -alias example.com

Untrusted self signed certificate:

Our certificate is obviously not trusted since it is self signed. A certificate signed by a CA will not exhibit a security warning. Like the one presented by google for the gmail login page, which is shown below

Trusted certificate from google.com:

When you start a proxy that has HTTPS support, say charles for instance, it does the magic by inserting its own certificate into the certificate hierarchy. The Charles CA Certificate, now becomes the root certificate in this hierarchy, allowing it to decrypt the information that is sent between the client and server.

Modified certificate hierarchy:

Charles signs the certificate that google presents, so it will now be able to decrypt the information that is sent by the server. However the side effect is that your browser will no longer trust this certificate since the root CA is not in your trusted store.

Untrusted connection due to modified hierarchy:

You can get over the problem by importing the certificate or installing it into the MS trust store. This is one technique that proxies use to debug traffic. Know of another method / proxy software ?  Leave a comment. Happy debugging