I have been experimenting with JavaMail api to fetch Google Apps Email as part of a product idea. Initially, I used POP3 protocol and tried to get the Inbox and that worked just fine. Then I wanted to get the remaining Folders. Well, Google Apps EMail (which is based on their GMail software), organizes by Labels and doesn’t use folders (except may be the Inbox, I don’t know all the details). When I used POP3, the only folder that I managed to get is the INBOX folder. Then I switched to using IMAP and interestingly, it returned not just INBOX bot also the the rest are the labels that I defined. The remaining such as “Drafts”, “Sent Mail” etc provided by default by Google were not present. However, there was a special folder called “[Gmail]” which contains the standard default folders. When debugging was enabled, it indicated that the “[Gmail]” folder had something like
* LIST (\Noselect \HasChildren) “/” “[Gmail]”
while rest of them had
* LIST (\HasNoChildren) “/” “[Gmail]”
Interestingly, with POP3, even the “[Gmail]” is not present. Not sure if this is related to Google’s implementation of the protocol or some limitations in POP3 vs IMAP.
JPasswordField and Console classes return the password as an array and a good practice is to blank out the array characters after making use of the password so that a memory dump won’t reveal the password. This is good. But then, today I am experimenting with JavaMail api and it has a PasswordAuthentication interface that has “public String getPassword()” method. Hmm, so what’s the point in ensuring that secure APIs are used only to make them non-secure in between? Sort of like loading a webpage using https but the form submitted getting posted to http.
This is my third of those rarely “hate java” moments. I documented one in 2008, then another in 2009 and now in 2010. Surely, it’s rare. Isn’t it? :).
On a side note, seems James Gosling said in a 2001 interview about Java
“One of the things that forced Strings to be immutable was security. You have a file open method. You pass a String to it. And then it’s doing all kind of authentication checks before it gets around to doing the OS call. If you manage to do something that effectively mutated the String, after the security check and before the OS call, then boom, you’re in. But Strings are immutable, so that kind of attack doesn’t work. That precise example is what really demanded that Strings be immutable. ”
Update: Now after all the effort I put in to still use System.console().readPassword() because useless on my Mac (OS X 10.6.3) because the “without echo” is not working (meaning the letters are echoing on the screen). Could be a problem with Apple’s version of Java or may be in the underlying OS X call. Don’t know, but now I am really annoyed.