jump to navigation

The Final Stretch June 17, 2008

Posted by Dmitri in Uncategorized.
1 comment so far

In the last post, I was stuck in about almost every respect I could think of, and things were looking grim. Robert Frost’s advice to take the path less travelled by clearly didn’t apply to my project. So we went back to the fork in the road, and got back onto the highway everyone uses: HTTPS POST.

I was quickly on my way – instead of the server throwing me back an exception when I tried to login, it gave me back something else: a “incorrect username/password” message. I double-checked, and they were correct. Already cursing all things holy, I set out to find out why.

The reason was simple enough – the hashed values of the username weren’t being hashed properly because of some native code that I copied over from the SlashID site. That native code referred to server-side variables that my extension obviously didn’t have access to, which resulted in the improper hashing. After discussing things with Zeev (the head honcho of this all), he proposed to add another servlet that my code will call that will provide us with the server data that I needed. This servlet was implemented over this past weekend.

So, since Monday, I fixed the hashing problem, and put in the call to the new servlet, and integrated the results with my existing code. For some reason SOP kicked in again (I’ll make another post about this interesting occurrence later), and after compiling the Java into JavaScript and putting it into the extension, and running it, I finally got the log messages I was aiming for all this time:

SlashID: Should redirect to SlashID member page here

when logging in directly from the extension or the SlashID page, and

SlashID: Trying to redirect to http://www.cryptotrust.com/wp-content/plugins/slashid/login.php

when logging in from a WSP (cryptotrust in this case).

Hallelujah!

Now all I have left is to implement the redirection, which is something I’m going to read up on how to do.

After that, all that will be left will be some final polishing up of code to get it ready to be released.

Coding actually became rewarding again.

Advertisements

The Three Stooges May 29, 2008

Posted by Dmitri in Uncategorized.
2 comments

So I’m stuck on every front I can think of:

When I run in Hosted mode, I get the error I posted about before.

When I debug in hosted mode, I get this interesting error in Eclipse:

source not found
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available
Method.invoke(Object, Object…) line: not available
IDispatchImpl.callMethod(CompilingClassLoader, Object, Variant[],
Method) line: 126
MethodDispatch.invoke(int, int, Variant[]) line: 88
MethodDispatch(IDispatchImpl).Invoke(int, int, int, int, int, int, int, int) line: 293
MethodDispatch(IDispatchImpl).method6(int[]) line: 196
COMObject.callback6(int[]) line: 117
OS.DispatchMessageW(MSG) line: not available [native method]
OS.DispatchMessage(MSG) line: 1925
Display.readAndDispatch() line: 2966
GWTShell.pumpEventLoop() line: 689
GWTShell.run() line: 550
GWTShell.main(String[]) line: 321

When I try and compile my code so I can try to run it in the extension directly, I get yet a third error:

Exception in thread "main" java.lang.NoClassDefFoundError: com/google/gwt/dev/GWTCompiler
Caused by: java.lang.ClassNotFoundException: com.google.gwt.dev.GWTCompiler
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)

Will continue to try to solve either one of these 3 problems

Captain’s log, stardate 8052.8 May 28, 2008

Posted by Dmitri in Uncategorized.
1 comment so far

In my search for the answer on how to fix that exception, I came across many different answers, some dealing with missing attributes (as posted earlier), some with Seriliazed issues, yet others with stuff I didn’t understand at all. I decided to create a thread on the subject so I can keep track of things people suggested, and which worked and which didn’t. The thread is here.

I’ve also found someone who seems to have had the same problem, but with no resolution either, unfortunately: click me

An Incrementally-Small Step Forward May 27, 2008

Posted by Dmitri in Uncategorized.
add a comment

Zeev was kind enough to point me to the servlet URL on the SlashID server, so I decided to try just plugging it into the <servlet> tag to see if it works. Kinda did – as usual, GWT complained about something, and I found out I had to change the URL I pass to setServiceEntryPoint() to be the same as the one I set in the tag. Compiled and ran, aaand got:
[INFO] com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: This application is out of date, please click the refresh button on your browser

I asked around about this exception, and was told that it’s because the server code is not in sync with my client code. Apparently, it can happen from me sending a user object that’s missing an attribute, but I don’t know if that’s the case here because I’m sending all 3 necessary String params to the server, so everything should be fine.

Investigating…

Some Questions Have Formed May 26, 2008

Posted by Dmitri in Uncategorized.
1 comment so far

Continuing where I left off, I now have a good understanding of how servlets work, although that doesn’t exactly answer the question on how to do what is needed: namely, access a servlet on a different server than the one from where the request is being made from. Traditionally, a service request to some servlet on a server comes from a webpage served to the client by that same server, so there are no issues with using the deployed servers.

The answer seems to lie in the

<servlet path="url-path" class="classname"/>

tag. The url-path mentioned “should be absolute and have the form of a directory (for example, /spellcheck).” I’m not sure about this, but it seems like a good idea to try to somehow provide the URL of the folder where the servlet is deployed on the SlashID server, and see if that works. So the first question becomes, “What is the URL of th deployed servlet?”

However, trying to access the servlet container remotely raises other questions: “Does my application have to do the servlet initialization? If not, when was the servlet initialized? How will my application know?”

There is a ton of info out there about deploying and using servlets in the traditional way (i.e. from a page served by the same server the servlet is on), but nothing that details what I’m trying to do, putting doubts in my mind about the feasibility of this.

One other possible solution I’ve considered is perhaps somehow using the standard HTTPS POST method to communicate with the SlashID server. If it worked with getEncryptedMasterSecret(), perhaps it should be possible with this as well. Of course trying this solution comes with its own set of questions about how to actually do it, but I think I’ll only worry about that if I don’t find any satisfactory answers to the questions posed in this post.

Ahhh Long Weekends May 21, 2008

Posted by Dmitri in Uncategorized.
add a comment

So this Victoria Day long weekend I went camping with my gf up to Barry’s Bay (Algonquin Park area). We were plagued by pretty bad weather all weekend – cold, windy, and rainy. On Sunday, it started raining at 8pm, and didn’t stop until 6am Monday morning, at which point it actually snowed for a good hour or so. Ironically enough, on Monday, the day we had leave, the weather turned out to be quite good. Not being able to enjoy the actual camping for pretty much the entire weekend, we wanted to make the most out of Monday, so we stayed as long as we could. Turns out we stayed a little too long, as we found out after we packed up that the gas stations in the area all closed, and I didn’t have enough gas to get us close enough to civilization where they have 24h gas stations. So we were forced to stay another night, and left for Toronto promptly at 7am. The point of all this is there wasn’t much opportunity to get any work done over the weekend.

It’s not all bad though. I posted a thread in the GWT Google Group explaining my problem, and got some replies. The thread can be found here. So I spent my time trying to run the code in hosted mode, to see if the problem persists. This was a challenge in itself as I abandoned testing our extension in hosted mode when we first ran into the problems with SOP. SOP prevented me from actually being able to test up to the point where the RPC call was made, so I had to abstract away just the RPC call so I could test it in hosted mode separately.

Of course, then GWT complained about all the XUL-specific code that was now present in the project, so I had to figure out how to force it to ignore the non-GWT-compliant code.

Eventually, I was able to call the login() RPC method from hosted mode. The toAppend error didn’t appear, and the call actually executed, although the onFailure() callback function was called, so something is still not right. This is the error I got back:
[TRACE] The development shell servlet received a request for 'main' in module 'com.slashid.web.SlashIDLogin'
[WARN] Resource not found: main
[INFO] com.google.gwt.user.client.rpc.InvocationException: Cannot find resource 'main' in the public path of module 'com.slashid.web.SlashIDLogin'

I asked around, and found out that this may be because I didn’t set the <servlet> tag in the *.gwt.xml file. It’s explained more here: http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.html#ModuleXml

The problem I think, is that the servlet itself is/will be remote from where it will be called. But I have to learn how the servlet mechanism works before I can figure this all out, and that is my current task.

Grrr setbacks as always May 16, 2008

Posted by Dmitri in Uncategorized.
2 comments

Getting an error that says,

Error: toAppend has no properties
Source File: chrome://slashid/content/E20C0D3A0B5676DBB9395C022DE2F5C4.cache.js
Line: 3285

inside the function

function java_lang_StringBuffer_$append__Ljava_lang_StringBuffer_2Ljava_lang_String_2(this$static, toAppend){
  if (toAppend === null) {
    toAppend = 'null';
  }
  var last = this$static.js.length - 1;
  var lastLength = this$static.js[last].length;
  if (this$static.length > lastLength * lastLength) {
    this$static.js[last] = this$static.js[last] + toAppend;
  }
   else {
    this$static.js.push(toAppend);
  }
  this$static.length += toAppend.length;
  return this$static;
}

which is a GWT-generated function (i.e. I didn’t write it explicitly) which makes it really annoying since it makes it really hard which line of my code causes it, or what causes it all, actually.  And I can’t debug it line-by-line with GWT’s hosted browser cause of the pain-in-the-ass SOP (Single Origin Policy).

Grrrrr.

For More Info May 14, 2008

Posted by Dmitri in Uncategorized.
add a comment

If you’re interested in finding out more about SlashID, you can check out this somewhat-amusing video we made explaining what’s going on:

Alternatively, you can go to the official website here where you can find the white paper as well as the protocols that are being used, and tons more in-depth information.

What is SlashID? May 14, 2008

Posted by Dmitri in Uncategorized.
add a comment

SlashID is a solution for web users who need to keep track of many login credentials for different web sites, and e-businesses concerned about the security of their data. It is an online password manager that is much more secure than the others because it stores all of its customers’ data in highly-encrypted form. However, there is a caveat with the current SlashID solution in that the client JavaScript that runs on the cient computer when they are logging in can still be compromised from within SlashID to steal the password and thus have the key to all of that customer’s private data. The solution to this is to develop browser plug-ins so that the users will not have to download any client-side JavaScript from SlashID when logging in, thus putting at ease the minds of the business owners and their customers about the security of their private information.

About the Project May 14, 2008

Posted by Dmitri in Uncategorized.
add a comment

Right now all work is being done on the Firefox project. A bit of background info about that: the SlashID login page (you can find it here) is created using Java code that was compiled into runnable page JavaScript using the Google Web Toolkit (GWT). Since the Firefox extension will be using the same login protocol, and since FF extensions are written in JavaScript (mostly, if you’re adventurous you can do it in C++), we decided it would be easiest to rip-out only the login-specific Java code, use GWT to compile it into JS, and then put that JS into the extension. This hasn’t worked as smoothly as it sounds (mainly because GWT compiles Java into webpage-specific JS, which is somewhat different from extension-specific JS), but with some hacking we got it to actually run through the login process, and log the user into SlashID itself.

Currently, I’m polishing up the Firefox extension so that it can actually be released to the public and be usable. The obstacle to overcome is to have a working redirection system so that when a user logs in successfully, they are automatically redirected to the member area.