M$ plans to end most sales of Windows XP on June 30 2008.
Let's sign InfoWorld's petition to ensure Windows XP continues to be available after the deadline because it's very inappropriate for M$ to be forcing the customer to make high impact changes to their business for zero gain.
Come on, sign it!
Sunday 2 March 2008
Tuesday 19 February 2008
Micro$oft's evil plans
Here's a very good story to read: Evangelism Is War
Here's a snippet of it:
Here's a snippet of it:
Our mission is to establish Microsoft's platforms as the de facto standards throughout the computer industry. Our enemies are the vendors of platforms that compete with ours: Netscape, Sun, IBM, Oracle, Lotus, etc. The field of battle is the software industry. Success is measured in shipping applications. Every line of code that is written to our standards is a small victory; every line of code that is written to any other standard, is a small defeat. Total victory, for DRG, is the universal adoption of our standards by developers, as this is an important step towards total victory for Microsoft itself: "A computer on every desk and in every home, running Microsoft software."
Monday 17 December 2007
Form submit weirdness in Opera 9.20
Here's one for you:
I have a few input form elements on a page, one of them is of type 'submit'. Because I don't use a form to submit this information, I set an event listener for one of the inputs like so:
Here's what happens: if the enter key is pressed in the text control,
I investigated the problem and here are a few observations:
My conclusion: Opera detects a 'submit' element and launches a click event on it when enter is pressed in one of the text input elements, assuming that they're all part of a form. I think this is not something a web developer would expect, would you?
I need the event listeners for Firefox, so I'm going to change the submit element to 'button' which is more appropriate anyway.
I have a few input form elements on a page, one of them is of type 'submit'. Because I don't use a form to submit this information, I set an event listener for one of the inputs like so:
onkeypress="if(event.keyCode==13)myAction()"
so that if enter is pressed, an action is performed. Similarly for the 'submit' input onclick="myAction()"
, so if the button is clicked the same action will be performed. Here's what happens: if the enter key is pressed in the text control,
myAction
is executed twice. It's executed only once if I click on the button...I investigated the problem and here are a few observations:
- If the type of the submit element is changed to 'button' the action is performed only once when enter is pressed, as expected
- If I remove the event listener from the text input element and leave the type of the 'submit' element unchanged,
myAction
is executed only once, as expected - What happens in myAction does not affect the form elements in any way,
myAction
can be replaced withalert
- This behaviour doesn't happen in Firefox
- In Firefox, only if the elements are in a form (and they are not in my case) then the form is submitted when enter is pressed in one of the text input elements
My conclusion: Opera detects a 'submit' element and launches a click event on it when enter is pressed in one of the text input elements, assuming that they're all part of a form. I think this is not something a web developer would expect, would you?
I need the event listeners for Firefox, so I'm going to change the submit element to 'button' which is more appropriate anyway.
Sunday 16 December 2007
RSA encryption
I recently started to develop a new web application. I want this one to run many windows, only one web page loaded fully at the beginning: index.php. Once this is loaded all the communication will take place AJAX style through the httpRequest object.
One of the challenges was authentication. SSL is out of the question, because I don't want any page refreshing or browser redirection and I also want to enable the user to keep the state of their windows in case the session expires. The logging in must happen through a window that asks for the user name and the password, sends the information to the server and if the credentials match, log the user in, keeping all the previously opened windows with all the data in them. Of course if a different user logs in, only public information will be kept in the browser, not information marked as private by the previous user.
I don't want the password to travel on the internet in plain text, I want to encrypt just the password. I don't want to slow down the interaction by using some very slow encryption algorithm that takes a lot of time to complete.
Before I made my decision, I had searched for some ways to encrypt information with JavaScript and I had found a lot of websites (here's an example) that provide encryption algorithms that require keys. I don't understand what's the purpose of these algorithms, if they require a key which needs to be sent to the client on the internet, then an attacker can intercept the key as well and decrypt the information with no problem. Perhaps they are designed just for use by one person offline to encrypt some data and store it somewhere along with the key?!?
One secure way to authenticate people to my web application could have been, MD5 encryption on the client side and sent to the server to compare to the stored MD5 of the password. There are several problems with this method:
RSA is by far the most popular cryptosystem and it's very secure. Because even though it requires some key exchange, there's a private key involved that doesn't travel between the server and the client. The most comprehensive and complete web site I found on this subject is this. I'm not going to talk too much about RSA, about how it works and why it's secure. Gaurav Saini's article explains everything.
The code Gaurav provided in his article encrypts and decrypts a number. What you need more is a way to generate the keys and a way to transform texts to numbers. As I said, I wanted something good enough without sacrificing speed (I'm not developing web applications for banks and the data used in this future web application is not very sensible). So instead of working with huge prime numbers as SSL does and generating them on demand, I chose to take a big list of prime numbers from this website, making sure that their product won't exceed JavaScript's integer upper limit. That saves a lot of processing time and to be sure they're not easy to guess, they are chosen randomly and assigned to either p or q with each request to the log in form.
I had to create a php version for the decrypt function as well, because their product and the 'phi' value is sent to the client from the server, the client encrypts the password and the server decrypts it upon receiving the information from the client. The password is then sent to the LDAP server along with the user name.
Transforming the text into numbers is the easy part. There are many ways, but I chose to use
I had a tiny problem with php because php's upper limit on integers is a lot smaller than JavaScrpt's. I wanted to use the GMP library to work with large numbers, but unfortunately php5-gmp can not be installed on Ubuntu JeOS :-( so I found another one that comes bundled with PHP5, MCMath which worked like a charm.
A more complete RSA implementation that works with large numbers can be found at this address, but it's not very well explained. This version is interesting, instead of encrypting each character, it uses a key of a fixed length, takes chunks of the text transformed to the digit code, adds the bit shifted value of the corresponding position of the key to make a large string of digits which is treated as a number and encrypted. However this algorithm relies on a Delphi library to generate the key, which needs to be changed depending on what you use on the server side.
Please tell me about your unique and innovative way of sending passwords from client to server.
One of the challenges was authentication. SSL is out of the question, because I don't want any page refreshing or browser redirection and I also want to enable the user to keep the state of their windows in case the session expires. The logging in must happen through a window that asks for the user name and the password, sends the information to the server and if the credentials match, log the user in, keeping all the previously opened windows with all the data in them. Of course if a different user logs in, only public information will be kept in the browser, not information marked as private by the previous user.
I don't want the password to travel on the internet in plain text, I want to encrypt just the password. I don't want to slow down the interaction by using some very slow encryption algorithm that takes a lot of time to complete.
Before I made my decision, I had searched for some ways to encrypt information with JavaScript and I had found a lot of websites (here's an example) that provide encryption algorithms that require keys. I don't understand what's the purpose of these algorithms, if they require a key which needs to be sent to the client on the internet, then an attacker can intercept the key as well and decrypt the information with no problem. Perhaps they are designed just for use by one person offline to encrypt some data and store it somewhere along with the key?!?
One secure way to authenticate people to my web application could have been, MD5 encryption on the client side and sent to the server to compare to the stored MD5 of the password. There are several problems with this method:
- the md5 can be intercepted and sent in the future by the attacker to log in as the victim.
- if you have an md5 hash and you want to know the text it represents, find a site that stores md5 hashes and search for it, if the password is pretty weak, it's a good chance you'll decrypt it.
- we use LDAP to log in people and ldap requires plain text password to be sent to it, so storing just the md5 is out of the question.
RSA is by far the most popular cryptosystem and it's very secure. Because even though it requires some key exchange, there's a private key involved that doesn't travel between the server and the client. The most comprehensive and complete web site I found on this subject is this. I'm not going to talk too much about RSA, about how it works and why it's secure. Gaurav Saini's article explains everything.
The code Gaurav provided in his article encrypts and decrypts a number. What you need more is a way to generate the keys and a way to transform texts to numbers. As I said, I wanted something good enough without sacrificing speed (I'm not developing web applications for banks and the data used in this future web application is not very sensible). So instead of working with huge prime numbers as SSL does and generating them on demand, I chose to take a big list of prime numbers from this website, making sure that their product won't exceed JavaScript's integer upper limit. That saves a lot of processing time and to be sure they're not easy to guess, they are chosen randomly and assigned to either p or q with each request to the log in form.
I had to create a php version for the decrypt function as well, because their product and the 'phi' value is sent to the client from the server, the client encrypts the password and the server decrypts it upon receiving the information from the client. The password is then sent to the LDAP server along with the user name.
Transforming the text into numbers is the easy part. There are many ways, but I chose to use
text.charCodeAt(i)
to get the unicode code of each character, encrypt it using the key provided earlier by the server, put the codes together with a char delimiter, decrypt each code on the server and transform it to character using html_entity_decode('&#'.$code.';',ENT_NOQUOTES,'UTF-8');
.I had a tiny problem with php because php's upper limit on integers is a lot smaller than JavaScrpt's. I wanted to use the GMP library to work with large numbers, but unfortunately php5-gmp can not be installed on Ubuntu JeOS :-( so I found another one that comes bundled with PHP5, MCMath which worked like a charm.
A more complete RSA implementation that works with large numbers can be found at this address, but it's not very well explained. This version is interesting, instead of encrypting each character, it uses a key of a fixed length, takes chunks of the text transformed to the digit code, adds the bit shifted value of the corresponding position of the key to make a large string of digits which is treated as a number and encrypted. However this algorithm relies on a Delphi library to generate the key, which needs to be changed depending on what you use on the server side.
Please tell me about your unique and innovative way of sending passwords from client to server.
Labels:
ajax,
encryption,
gmp,
javascript,
rsa,
SSL,
ubuntu
Friday 17 August 2007
Firefox 2.0.0.6 vs Opera 9.20
This post is not just to let you know what browsers I'm using at the moment.
It's rather about this speed problem a colleague of mine and I are having for a web application.
Just to make it simple, there are two divs, each contain a huge table, each with around 100 rows of 20 columns each, in each cell there is either some text, a checkbox or a select tag with around 5 options. Just to sum things up, there are like 800 checkboxes and 800 selects. They are loaded by pulling data from the server through a HttpRequest object.
We were expecting loading to take a long time and it really does :-)
What is really surprising is what happens when they're both loaded and their classNames are changed, one gets a class name that has among others "display: none" to hide it and the other gets "currentDiv" class name which sets a few properties.
I'm really surprised about how ling time it takes Firefox 2 to do this operation. I checked with FireBug exactly what part of the code takes the most to run and this is it:
myDiv.className = "currentDiv";
This is where it spends around 10 seconds.
I thought instead of changing the class name, to try and change the style.display property, but there was no visible difference. Here's a nice test on this subject.
Just for tha hell of it, I also took down any other CSS properties from the "currentDiv" class and especially these kind of lines:
div.currentDiv table td.commentTd{ ... }
I thought maybe the rendering engine has to go through all cells of the table in this specific div and change the visual attributes. Well, again, no improvement.
I was curious what had Opera to say about this matter and I tested the same code on Opera 9.20. Result: under 2 seconds including loading the div. Absolutely surprising.
I'm not giving up on Firefox, yet, I still love it :-) But I'm looking forward to Firefox 3 with its new and improved JavaScript engine ;-)
It's rather about this speed problem a colleague of mine and I are having for a web application.
Just to make it simple, there are two divs, each contain a huge table, each with around 100 rows of 20 columns each, in each cell there is either some text, a checkbox or a select tag with around 5 options. Just to sum things up, there are like 800 checkboxes and 800 selects. They are loaded by pulling data from the server through a HttpRequest object.
We were expecting loading to take a long time and it really does :-)
What is really surprising is what happens when they're both loaded and their classNames are changed, one gets a class name that has among others "display: none" to hide it and the other gets "currentDiv" class name which sets a few properties.
I'm really surprised about how ling time it takes Firefox 2 to do this operation. I checked with FireBug exactly what part of the code takes the most to run and this is it:
myDiv.className = "currentDiv";
This is where it spends around 10 seconds.
I thought instead of changing the class name, to try and change the style.display property, but there was no visible difference. Here's a nice test on this subject.
Just for tha hell of it, I also took down any other CSS properties from the "currentDiv" class and especially these kind of lines:
div.currentDiv table td.commentTd{ ... }
I thought maybe the rendering engine has to go through all cells of the table in this specific div and change the visual attributes. Well, again, no improvement.
I was curious what had Opera to say about this matter and I tested the same code on Opera 9.20. Result: under 2 seconds including loading the div. Absolutely surprising.
I'm not giving up on Firefox, yet, I still love it :-) But I'm looking forward to Firefox 3 with its new and improved JavaScript engine ;-)
Wednesday 15 August 2007
Prevent browser caching of web pages
I'm having problems with cached web pages in some of my web applications.
There is this particular application that is in continuous development, while employees are using it and whenever I make some modifications the old version conflicts with the new one throwing errors or displaying some mixed information: some from the old html code and some new information the web page retrieves by AJAX.
I got a fix for the html code, now it isn't cached any more. I use this code in PHP:
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Tue, 29 Mar 1983 07:20:55 GMT");
This really works, everything I modified in the PHP code is updated every time someone browses the web page, but not the JS and CSS files that are linked from the html code :-(
I found some more tips for preventing caching here. They consist in adding some meta tags in the head section of the web page:
<meta http-equiv="expires" value="Tue, 29 Mar 1983 07:20:55 GMT"/>
<meta http-equiv="pragma" content="no-cache"/>
The value of the first one is a date in the past, obviously. I'll let you guess the miracle that happened on that particular date I chose to put in there :-)
I tried this as well and it doesn't work for js and css files, unfortunately :-(
This wouldn't have been a problem if my js code was inline, but I never insert inline JavaScript code if there are more than 20 lines. I always like to split the code in many files each representing a module that can be taken and put on another website and works without changing anything except maybe a few variables.
Another idea was to send a header for each js or css file, but that would mean changing the js and css files to .php and send the headers I wrote at the begining of this post. I really don't want to do that, I want to keep them as js and css, because it's makes the application neat and organised. Many editors highlight code according to the file extension, I don't want to switch to choosing manually the highlighting style.
Some other ideas I got from Matt Raible and this forum. The idea is simple, very simple, just add a random number as a variable sent by GET method. This will foul the browser to think that it's always a new file without affecting the file itself.
Some other idea is to use subfolders for each version and just change the version folder in the path provided in the html code. This won't be a big problem because I use this piece of code to load dependencies, if versions change, I'll need to change only the main file that loads the dependencies, but others might find this annoying.
These last methods work fine, problem solved. But thinking about optimisation, the js and css files will never be cached so I lose one of the most important advantages I got by using external files, exactly what I want to get rid of: caching. Caching is meant to store information that is used often instead of loading it again and again.
As I don't update these files so often I decided to use a combination of all these methods. I use the headers to make sure the html code is always updated (usually there isn't too much html code in my html files, so not too much overhead ;-) ). I added a variable called version to the end of the file and I update it when I want the code in js and css files updated as well.
Here are the sample lines:
<link rel='stylesheet' type='text/css' href='stylesheet.css?version=3' />
<script type="text/javascript" src="js/toolbox.js?version=3"></script>
Don't forget to update the version number to the files you load dynamically from other js files!
There is this particular application that is in continuous development, while employees are using it and whenever I make some modifications the old version conflicts with the new one throwing errors or displaying some mixed information: some from the old html code and some new information the web page retrieves by AJAX.
I got a fix for the html code, now it isn't cached any more. I use this code in PHP:
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Tue, 29 Mar 1983 07:20:55 GMT");
This really works, everything I modified in the PHP code is updated every time someone browses the web page, but not the JS and CSS files that are linked from the html code :-(
I found some more tips for preventing caching here. They consist in adding some meta tags in the head section of the web page:
<meta http-equiv="expires" value="Tue, 29 Mar 1983 07:20:55 GMT"/>
<meta http-equiv="pragma" content="no-cache"/>
The value of the first one is a date in the past, obviously. I'll let you guess the miracle that happened on that particular date I chose to put in there :-)
I tried this as well and it doesn't work for js and css files, unfortunately :-(
This wouldn't have been a problem if my js code was inline, but I never insert inline JavaScript code if there are more than 20 lines. I always like to split the code in many files each representing a module that can be taken and put on another website and works without changing anything except maybe a few variables.
Another idea was to send a header for each js or css file, but that would mean changing the js and css files to .php and send the headers I wrote at the begining of this post. I really don't want to do that, I want to keep them as js and css, because it's makes the application neat and organised. Many editors highlight code according to the file extension, I don't want to switch to choosing manually the highlighting style.
Some other ideas I got from Matt Raible and this forum. The idea is simple, very simple, just add a random number as a variable sent by GET method. This will foul the browser to think that it's always a new file without affecting the file itself.
Some other idea is to use subfolders for each version and just change the version folder in the path provided in the html code. This won't be a big problem because I use this piece of code to load dependencies, if versions change, I'll need to change only the main file that loads the dependencies, but others might find this annoying.
These last methods work fine, problem solved. But thinking about optimisation, the js and css files will never be cached so I lose one of the most important advantages I got by using external files, exactly what I want to get rid of: caching. Caching is meant to store information that is used often instead of loading it again and again.
As I don't update these files so often I decided to use a combination of all these methods. I use the headers to make sure the html code is always updated (usually there isn't too much html code in my html files, so not too much overhead ;-) ). I added a variable called version to the end of the file and I update it when I want the code in js and css files updated as well.
Here are the sample lines:
<link rel='stylesheet' type='text/css' href='stylesheet.css?version=3' />
<script type="text/javascript" src="js/toolbox.js?version=3"></script>
Don't forget to update the version number to the files you load dynamically from other js files!
Thursday 26 July 2007
Subscribe to:
Posts (Atom)