Category ‘Web Development’
Thunderbird IMAP push email
Using Thunderbird as the e-mail client of your choice and the IMAP protocol to fetch and manage your mail?
RFC 2177 defines IDLE, an extension to the IMAP protocol allowing mail clients to change into an idle mode while keeping the TCP-connection open. This allows the servers to notify the clients of new mails on arrival (the so-called push e-mail).
Not all e-mail providers support IMAP IDLE, though – you should check whether your mail provider supports it by opening a telnet connection to the IMAP server (standard port for IMAP is 143) and sending 001 capability. If the answer contains „IDLE” your server supports IMAP IDLE.
GMail for example answers
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY
001 OK Thats all she wrote!
There's one thing to look out for, though – Thunderbird only sends the IDLE command (effectively enabling push e-mail) if you disable the „check for new mail every nth minute”-option. I could not find any documentation on that feature – however using Help » Mozilla Thunderbird Help causes a 404 File Not Found error for me anyway (using the German version of Thunderbird).
Steve Jobs would say: „Exchange for the rest of us” – using GMail, IMAP and Thunderbird.
Probably the biggest RSS icon I have ever seen
There’s a certain trend in so-called web 2.0 design to have ever bigger icons for RSS feeds (What are RSS feeds?).
Now I recently saw an RSS icon that beats the pants of all other RSS icons I’ve ever seen before: ImageShack’s RSS icon (screenshot):
This icon is a whooping 403 per 336 pixels large - that’s 135,408 square pixels!
A rant on limited password fields
You register for a new service, type in all your details, choose a password - and after 16 characters the password field stops accepting your input.
Whenever I see a password field that’s limited in it’s length I loose some trust in the organization providing the form. Why? Because the only valid reason I see to limit the length of a password is unencrypted or reversible encrypted storage. This requires some insight knowledge on how data is stored in databases: when defining a text field you usually have to choose it’s maximum length - obviously you could just choose whatever maximum length was possible, but that’s not the point of a well designed database. It would take me too long to explain that here, but there are some reasons why you certainly wouldn’t want to define fields longer than needed.
Password encryption methods
There are several different approaches to password encryption; the first and probably worst method is no encryption. It’s advantages are that you will be able to mail the password out to the user in case he forgets it and that it doesn’t require a lot of storage (estimating the average password length at about 10 chars from personal experience here). However it’s downsides are huge: in case you have some security flaw in your application all passwords will be leaked.
The second way is to use some encryption algorithm, e.g. AES or DES (those two might be a bit overkill, but there’s others). Strings encrypted with such an encryption algorithm generally tend to use up a lot more storage than the unencrypted string. You still have the advantage of being able to send the password to the user and if your database is leaked, the passwords will still not be decryptable (as long as the encryption key isn’t leaked).
However, there’s a better solution: hashing the password will give you a fixed-length string (which is great if you’re working with databases) from a variable-length string (=password) and it’s non-reversible. Theoretically you’d be able to calculate a so-called “collision”. Because a hash function is mapping an endless amount of strings to a finite amount of hash values there’s multiple strings with the same hash value. However given a certain minimum length of the password (which can be enforced by padding the string with random data you also store, the so-called “salt”) the effort to calculate such a collision is that large that it’s virtually impossible to hit one while your site is online (assuming you to re-setup the system once in 100 years here). Maybe you’d ask how to compare passwords on login if they’re stored using a non-reversible encryption? Actually you wouldn’t. You would instead hash the password the user entered with the salt stored for the user and compare it to the stored encrypted password. That way the unencrypted password is never in the server RAM and not in any log files either.
And what if a user forgets his password? Well, instead of mailing him his password, you could just generate a new password, encrypt it, store it into the database and send the new password to the user.
Also the hashing method allows you to enter virtually every character regardless of things like the encoding the database uses internally. Because hashing functions work with binary data and usually return a string using 0-9 and a-f (which are always the same in any encoding relying on ANSI) there won’t be any problems with the database encoding to deal with either.
So, why is there still services not allowing long passwords and all characters in passwords?