I saw this morning that VoodooPad Pro 4.1.2 was out with a handful of fixes for little bugs that seem to focus primarily on the iPhone app interaction. Since I'm not an iPhone owner, this doesn't really effect me, but I understand that this is where everyone is right now, so I have to deal with it.
Nice to see progress.
I've been working on the idea of getting the logged in user name into JavaScript so that I can make my little web app allow (and disallow) people without having to resort to JSP pages and login pages with security profiles, etc. Basically, I wanted to get the username, send it to the server for verification, and then if it's OK, show the data, if not, then don't.
I had no idea it was going to be this hard. In retrospect, I should have known, it's not something that Google or Firefox wants to allow as it's a security hole, but come on, folks there are a ton of legitimate intranets where, like us, it'd be ideal to have the username picked off and then used as the basis for simple permissioning. That way, we can use the XP login as the 'rules' for passwords, duration, etc., and if they are logged on, then they have to be who they say they are.
Anyway, I looked at a lot of different techniques. Turns out, the one that's the easiest to do is IE, but that's the one that I can't use because it's got a horrible JavaScript engine, and it's simply not stable enough to use. For IE the JavaScript is as simple as:
var info = new ActiveXObject("WScript.network"); alert('user is: ' + info.UserName);
which is a security risk, yes, but it's something that can be handled in the trust system within IE. It's clean, and I wish Chrome and Firefox had been as nice.
For these guys, I had to use a small Java applet. The code was simple enough:
import java.awt.*; import java.applet.*; public class Bridge extends Applet { /** * This method returns the user that's logged into the box this * applet (and therefore, web browser) is running on. It's a quick * way to get a basic authentication going. */ public String getUsername() { String who = "unknown"; try { who = System.getProperty("user.name"); } catch (Exception e) { // any exception means we get the default } return who; } }
Because I'm using Tomcat 6, and there are security restrictions on the accessing of things within the WEB-INF directory, I needed to place the source code (notice, there's no package statement at the top of the file) in the root of the src/ directory in the project. The ant target compile would build it, but then deposit it in the directory WEB-INF/classes - no good to leave it there - the browser won't be able to get at it. Additionally, there's no reason to package this one class into a jar file - it can be used as-is, as a .class file - we just need to make it available.
So I made a slight addition to the compile target in my build.xml file:
<!-- Copy special applet class files to public area --> <copy todir="${build.home}"> <fileset dir="${build.home}/WEB-INF/classes/" includes="*.class"/> </copy>
so that when all the source java files are compiled into their class files, the ones that do not sit in a package are copied to the root of the web app, and therefore, are publically accessible.
Once we have this all built, we need to have the applet incorporated on the page. Since the class file is at the root of the web app, we can simply say:
<applet code="Bridge.class" name="bridgeApplet" height=10 width=10> </applet>
and then in the JavaScript initialize() method for the page, we can have:
var username = document.bridgeApplet.getUsername(); if (username == 'joe') { ... }
where we're allowing 'joe' to do something, or not, as the logic may be. Unfortunately, we're not all done yet. There's the little problem of the security manager for the Java applets. It's not going to allow us to do this quite yet.
What we need to do is to have a java policy file placed into the 'home' directory on each OS that reads:
grant {
permission java.util.PropertyPermission "user.name", "read";
};
and any other properties you'd like to allow to be read. For this example, it's just the 'user.name', but there are others, and you can add them as you like.
The last trick is where to put this file. On linux, it's easy - 'home' is 'home', and you place it at ~/.java.policy and restart Firefox and you're good to go. The policy file will allow the applet to read the property, the JavaScript will get it from the tiny applet, and everything will be OK.
On Windows/XP it's a little different - C:\Documents and Settings\username\.java.policy but it's the exact same file. Since this is the roaming profile for a user, it's not horrible, and it's only the one property.
This doesn't look like much, but it's taken me several hours on the weekend to come up with ideas that didn't work, and then most of the day today to try to come up with something that actually did work. But, in the end, I have something that works, and I can use the simple approved list in a database to drive who can see the tool. Not bad.
[4/21] UPDATE: I was thinking about this morning, and I really came to the conclusion that the .java.policy file wasn't the right thing to do. It was going to be a lot better if I just created the self-signed certificate and then signed the jar. Then, once they accepted the certificate, they were good to go for all the things I write. Much better.
So, to make the certificate, I did the following in the root of the project I was working on:
$ mkdir cert $ cd cert $ keytool -genkey -keystore key.store -alias RATcert -validity 3650 ...answer questions...
the -validity 3650 says that the certificate should be valid for 10 years (more than enough) and the questions just need to be answered. Don't forget to write down the keystore password and then the alias key password - if it's different from the keystore password.
Now that you have the certificate created, you need to sign the jar. I added the following to the ant target compile in place of the 'copy' action that I mentioned above:
<!-- Create applet JAR file --> <jar jarfile="${build.home}/firecache.jar" basedir="${build.home}/WEB-INF/classes/" includes="*.class" /> <signjar alias="RATcert" keystore="${cert.home}/key.store" storepass="keystore-password" keypass="cert-password"> <path> <fileset dir="${build.home}" includes="*.jar"/> </path> </signjar>
where I'd added the property in the build.xml file:
<property name="cert.home" value="${basedir}/cert"/>
so that I can reference the location of the certificate keystore that I created above.
There's a nasty wrinkle with calling even a signed java applet from an unsigned JavaScript method. Turns out that the security model falls back to the lesser of the two. In this case, it means that even if I sign the jar, I don't get anywhere. What I found was that I needed to add a little code to the Java applet and then everything worked:
import java.awt.*; import java.applet.*; import java.security.*; public class Bridge extends Applet { /** * This method returns the user that's logged into the box this * applet (and therefore, web browser) is running on. It's a quick * way to get a basic authentication going. */ public String getUsername() { String who = "unknown"; who = (String) AccessController.doPrivileged(new PrivilegedAction() { public Object run() { who = System.getProperty("user.name"); } }); return who; } }
The use of the doPrivileged() method seems to be allowing the applet to run at it's security level and not that of the less-secure JavaScript that is calling it. Interesting, but it was a pain to find this one.
The final thing is the change in the applet tag in the HTML to reference the class file in the signed jar:
<applet archive="firecache.jar" code="Bridge"
name="bridgeApplet" height=10 width=10>
</applet>
Note that because the Bridge class file is in the root of the jar file, you don't want to have the ".class" on the end. This makes it possible to deploy the jar as signed and then the user can just accept it and we don't have to have the .java.policy file. This is a lot better.
I was trying to find a syntax error I had in my JavaScript today, and realized, once again, that the tools built in to the browsers on Windows/Linux (Firefox and IE) are pretty sad. Sure, Google Chrome has a little more, and Safari 4 beta as well, but I was on linux and that meant Firefox, and it wasn't really helpful.
Then I asked a co-worker, and he said he'd used a Firefox plugin Web Developer to debug JavaScript. So I downloaded it and tried it out. What a difference! This is what I was looking for all along. Something that points out the line with the error and at least some sense of the problem.
WIth this, I was able to diagnose my problem in no time. Thank goodness.
I was working on my web app today and my boss stopped by to say that it was probably a good idea to add in some kind of checking to see what browser is being used and only allow those that we know are stable - Google Chrome and Firefox 3. I was thinking that I'd have to do it in a JSP - take the entire page I'd had and make it a JSP and then do the checking there, but in reality, I can do it all in JavaScript.
I googled around and found this page where a pretty nice version of the browser detection is done. It's simple, fast, extensible, and works perfectly for my needs. Sure, I agree with the page and saying that this is not the best way to make a system cross-browser, but that's not what I'm after. I know which browsers are OK and which ones aren't. And it's got nothing to do with the capabilities - it's the stability of the JavaScript engine. So I really did want something as simple as letting me know the browser and version.
I put this into my code and then simply set the innerHTML value of a div that was to be the graph on the page to a simple paragraph explaining why we weren't able to show the data, and what they needed to do in order to see it. Basically, get Chrome and try again.
It's a pretty sweet little bit of code. Nice to have around.
I was a huge fan of Hotmail when it was first introduced. I loved that they started with their entire infrastructure being linux boxes - when the easy path was to choose Windows. I used it, told everyone about it, and loved the independence of it. This was years before Google was even a search engine - let alone "gmail". So the idea of a free web-based email was new. There was Yahoo, but that was limited unless you were a paid subscriber, and there was Hotmail.
Then they got bought up by Microsoft, and the slow dive began. It was clear that they wanted to show that they could build the same great service on Windows, but in the end, it was a miserable failure in the first years. I had almost given up on it. Then it started to come back. MSN IM was the first real decent thing of that old system, and then things built on that and got better. Now, it's decent, but completely overshadowed by GMail.
However, they haven't really caught up to GMail because they haven't allowed generic POP/IMAP access to the mail system. Until now, that is. Sure, there was a plugin for Mail.app that would talk to Hotmail, but that was a bit of a hit-n-miss proposition, and I never really used it because I couldn't really trust it. Now, it seems, we have complete POP capability with SSL encryption to Hotmail.
This hint really goes through most of it, but the big points are these:
When you're done setting it up, Mail.app will recognize that this server allows SSL (excellent!) and it'll be ready to go. Very nice to not have to have Firefox up and running to see emails from Hotmail anymore.
This morning I checked Software Update and noticed that there was an update to iMovie ro fix a problem:
This Software Update fixes an issue with projects having a size of 0 KB. Attempting to open these projects would cause iMovie to quit unexpectedly at launch.This Software Update also addresses a problem where full-screen mode could not be accessed on some systems.
Not that I've heard a lot of issues from the kids on iMovie, but I was looking at some video from vacation and know that I'll want to be stitching it together so I certainly wanted to update.
I'm not a very good traveler. I get motion sick, I don't like the seats in commercial airliners as they are a touch too small for my 6'4" frame, and I don't like all the crowds at airports, etc. But I like vacations. I also like coming home. This vacation was a doozie in that we got to snuba with sting rays and also got to zip line hundreds of feet up in the canopy of the Jamaican hillside.
I loved the former, and was simply too scared to even scream on the latter. But Liza had a tough time with the rays and loved the zip lining. Seems fair. Symmetric. And the rest of the cruise was pretty nice. I think we realized that we're not really cruise people. We aren't really fond of the crowds. I ran every morning - save the last, as we had to disembark at 9:30 am and that meant getting everybody up and out early. But still, it was something that I'm glad we did. Something we needed to do so we'd know we don't need to do it again.
I'm not sure what out ideal vacation is, but the trip to Mexico was a lot closer than this cruise. Not that it was the cruise line's fault. I think they did exactly what they said they'd do, it's just a little matter of expectations. Ours were pretty high, and the reality was that it's really targeted for people that like being around big groups of people. The pools were crowded except for very early in the morning and very late in the evening. The breakfasts were a bit on the crowded-side, but really, it was all probably a matter of getting used to the way it's done on cruises.
It was fun to be on vacation... but it's great to be on the way home.
While I was on vacation it seems they released a new version of MacVim - Snapshot 45 and includes refactoring for the front-end as well as fixes to the ATSUI renderer. I haven't run it through it's paces yet, but I've got it and it seems to be running just fine.
Excited to see what they did while I was on vacation!
I was talking to a co-worker today and he mentioned that there was a Firefox setting, in about:config that would make Firefox release all it's used memory if it was minimized. This sounds very nice. So here's the deal: pull up about:config, look for the setting config.trim_on_minimize and if it's there, make it 'true'. If not, then right-click in the main section of the preferences and add it.
Restart, and you're done. Pretty neat.
I've got it set up on my work Firefox, and we'll see if this allows us a little relief on the JavaScript memory usage. I'm hoping it does because then when it's minimized, it's out of the way. That would be very nice.
UPDATE: you have to minimize all Firefox windows in order for this to kick in. Not exactly hard, but you have to remember to minimize everything. Nice to have in your pocket if you have things like the Google Visualization widgets on your pages.
I have been noticing the problems that my web page runs into when dealing with lots of data for the AnnotatedTimeLine. In Firefox 3.0.8, if I even fetch the data, I have a potential leak situation. It seems to be functioning a lot like the Java garbage collector where it'll let the memory rise, and then collect a bunch. I was trying to figure out where this was - in the JavaScript on my end, or in the Google code, when we decided it would be a good idea to try Google Chrome and see if it's 'independent threads for each page' idea would yield better results.
I'm glad I did.
It turns out that the JavaScript engine in Chrome, and possibly it's use of WebKit, makes a big difference in the memory stability of my page. Also, the debug capabilities are far better than those in Firefox. I can see the memory usage of each page and plugin separately. This fact alone made me realize that it's not in the Flash plugin. It's in the JavaScript.
This is good news because Chrome is a much better JavaScript engine, and it's funny, because it's because of the AnnotatedTimeLine that I need to have a superior JavaScript engine in the first place. Sort-of like they made the problem, and then realized that they needed to make the solution as well.
So I'll be looking more heavily at Chrome in the coming weeks. It's got a lot of promise, and while I'm not sure I'll use it on my Mac, as it's got WebKit and SquirrelFish in Safari 4 (Beta), it's nice to know that something with that level of capabilities is available on Windows. Not bad at all.