Once again, we have a 'security and stability' update from the Mozilla crew for Firefox. This time, it's an update to 3.0.9. It's not bad to update my Mac, but at work, on linux, it's a pain as it's an RPM and not allowed to auto-update.
Still... it'd be great for them to get a better JavaScript engine into their code so I can use it freely without crashing on my web app. They will... eventually.
This morning I read about something new out of Google Labs - an Open Source 3D viewer for the browser call O3D. The Mac plugin is at version 0.1.34.2 and while it's still a little rough around the edges, it's got something there that is worth looking into. VRML just hasn't really taken off, and I thought that was going to be a beautiful solution for complex visualizations. It just never found critical mass.
I'm looking at O3D and hoping that with the Google backing, it's going to have a lot better chance of being the web standard for complex, 3D visualizations. I'm not looking for a game engine, or a general drawing package - both those exist built on OpenGL and other technologies. No, I'm looking for the tool to easily represent 3D spaces (real and imagined) so that, for example, the output of a 2D solid-state simulator can be visualized from many angles, etc., using 3D and color. It's a powerful idea.
So I got O3D for my Mac, and we'll see how it evolves. Like I said, it's got a long way to go, but I'm hoping it makes it.
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 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.
I was reading today that the Google App Engine now is allowing an 'Early Look' at Java. This is really interesting based on the work I've been doing with servlets and the Google Visualization API. Interesting, to be sure. I took a little time today and read up on what they are offering. It's interesting. There's an Eclipse plug-in that can do it all, you just need to write the code. It's got a test framework built-in... not bad. I'm sure the Python version is as nice or nicer, but it's a big advantage to me to be in Java for all the Java tools I already know about.
So, it's something to consider. At this point, I can't see myself using it without a really good reason. It's putting yourself at non-trivial risk, and the lack of cost isn't that big a deal right now, but it's got the Google 'cloud' behind it, and that's nice.
SOmething to consider.
Well, I got one thing figured out - the bottom 'graph' on the Google AnnotatedTimeLine is a graph of what? Well... it appears that it's a graph of the final column in the dataset. Odd, but I guess that's one way to look at it. I might have liked it to be the first, but that's only because I have the total in the first column (after the date/time). Interesting.
I suppose that now I could move the total to the last column, but that would take a bit of effort, and based on the discussion I started on the Google Groups, it looks like I'm not the only one that's interested in this being a little more flexible. Here's to hoping that they respond with some flexibility in this.
[4/16] UPDATE: the last message in this thread was from VizGuy at Google:
- Its the last data series.
- Its a logarithmic manipulation of this data.
- We have an open feature request to let the users control this data.
- For now, you can hide this part of the chart (displayRangeSelector:
false). I know its not perfect, but for those who get crazy, it might be
better than leaving it as is... 🙂
From this, it's clear that I'm not alone in my confusion and the solution wasn't at all clear. Saying it's a logarithmic manipulation of the last column is really not at all clear. But it's on their list of things to do, and that's going to have to be enough. If I really wanted it to mean something, I'd move the totals data to the last column.
This morning I saw that OsiriX, the medical image viewer, released a new version, so I had to go get it. There's nothing quite like getting your images (x-rays, MRI, etc) and being able to look at them at home. Not that we're doctors and can read them, but it's fun to look at your guts and wonder Hey, is that a tumor?
If you have medical images, give it a try.