« March 2003 | Main | June 2003 »

May 2003 Archives

May 5, 2003

Axis of Cookies

I swear, some times it feels like I spend more time reading third pary code to see what it's really doing than writing code of my own. Today's subject of abuse will be Apache Axis. Here's the use case: Using a java plug-in applet inside a web-app that uses form based authentication access a soap service behind that authentication. You don't have the password available (there are tricks to get the username, but you really have to think outside the box to intercept the password, and forget about C3 certification at that point!)

My first line of thought was that Cookies are magically added to URL requests in the plug in so it must work in axis. That is a cool and very real feature of the plug in, but it only works when using a java.net.URL, but Axis dosen't use it, it uses some custom HTTP sender with support for the Jakarta Commons HTTP Sender. Thank you for plauing try again.

What worked for a while was the URL re-writing method form the servlet spec, basically using http://shemnon.com/speling/;jsessionid=<sessionID>. That works fine on some servers, but not others. The hitch is that in the spec URL re-writing is only meant to be used when the client rejects the cookies. One app server accepts the session id in both the cookie or the url re-writing, but anohter one we need to support doesn't. And you know what sucks? It's the second app server that is probobly properly implementing that part of the servlet spec! We're not playing horseshoes here so I need to keep going.

So as little as I want to I have to dive into the JAXRPC spec. The truth is that Axis's WSDL2Java is so easy to use from a coding perspective you rarely need to use the standard APIs that it implements. It just looks like another RMI-style interface that maigcally works. Believe me, I like stuff that magically works, it allows me to go home after my 8 hours are in.

It turns out that the classes you get from the ServiceLocaters are also javax.xml.rpc.Stub classes. These provice access to some standard properites, like if I needed HTTP Basic authentication I'de be in luck, but alas no dice, I need to use the currently bound user. There is also another standard property that will maintain the http session but it maintains only new sessions! And it suckes when all you get is "302 Found" messages to the login form when you don't know the password. And apparently the session is only maintained on a per-service basis as well (per instance of the serivce to make things worse).

This is where open source and source available software comes in handy. After diving into the setMaintainSession(boolean) code deep inside of the transport handlers I came to the conclusion that the cookie was stored in a property set that inhereited ultimatly from the same properties that the service uses to read the standard JAXRPC properties. So all I need to do is set the cookie in the service session when I get it from the service...

import org.apache.axis.transport.http.HTTPConstants;

/* ... */

MyServiceLocator locator = new MyServiceLocator();
MyService serivce = locator.getMyService();
((javax.xml.rpc.Stub)service)._setProperty(
    "javax.xml.rpc.session.maintain"),
    Boolean.TRUE);
((javax.xml.rpc.Stub)service)._setProperty(
    HTTPConstants.HEADER_COOKIE,
    "JSESSIONID=" + sessionID);

and those last two statements only cost me one afternoon of lost time....

Lame Excuses

Yea, it's been a while. In addition to the traditional aggressive work schedules throw in a few weekends of paintball, a new GameCube (Zelda rocks! the graphics are amazing) and going to Denver 5 of the last weekends to see my side of the family, one weekend had two trips and another had a trip to the inlaws! Because of my work schedule blogging durring the work day is out, and when I get home I am computer burnt out, and that's when I'm not watching the 6 TV shows I follow (I know, but it's the DVRs fault I can follow them!) Americal idol is a 2 night commitment and 24? Well you just can't not watch anymore. Enterprise, Survivor, Friends, and that '70s show are just because I am weak.
So there's my lame excueses.

May 8, 2003

All Your Hardware are Belong to NGSCB

CNet has an intersting article about how Microsoft is going to integrate NGSCB (the technoloy formerly known as palladium) into the Windows GUI. Windows that are secure and have what should be considered confidential will actually have a different look to them. It's a good thing they are letting the themeing stuff simmer for a couple of years so whent hey need it it's well done. Although most Linux windows managers woth using do this already: I can make telnet windows to sun boxes have an openwindows look and feel to them to remind me I sholdn't try wacky linux commands there.

There was one glimmer of hope however...

NGSCB will not be integrated into Longhorn, which is due in 2005, but will instead come out as separate software, [Microsoft: A separate look for security]

Oh good, it won't be completely crammed down our throat, not without our permission.

...Over time, pieces of the technology will be integrated into the coming operating system.

But it's gonna be like the catalytic converter. Optional at first, then mandatory, then "leaded fuel" (aka commercial software not useing NGSCB) will disapper. Maybe if we are lucky it will be more like caffiene free diet coke, widely available at firt but then only avaliable if you know where to get it, but still out there.

Note to self: don't eat fast food after 3pm. Second note to self: don't eat fast food.

May 9, 2003

Independent Developers and the JCP

Share Me Technolgies recently wondered How Many Independent Developers Join JCP? Well, I used to be a member, back before I got married, but not any more. Here's my experience:

First, as an individual you don't have to pony up $2000 to $5000 if you want to join as an individual. It's something on the order of $100 (this was back in Y2K, so things may have changed). But they will ask to make sure you are truly joining as an individual and not for your company as a way to save money. That's one of the biggest reasons it's not publicly listed. And it's not like a magazine subscription, don't forget to renew or cancel (unless you want some cratchety lady calling you up and berating you when you say "oh I thought I'de just let it expire").

What do you get when you pay? First you get earlier access to some of the specs that come outt of some of the JSRs, but it's not like a public draft, these are under NDA so you can't tell anyone or do aonything public with them. These are the community drafts. And that's all you get ... unless you get involved in a JSR.

JSRs are where the real action occurs. The loweset level of JSR involvement (that can be termed involvement) is as a member of the expert group. Basically all that does is it means you get even earlier access to the JSR drafts (and are under an even tighter NDA for them) and you get to talk on a mailing list to the spec lead who is responsible for delivering the spec (they usually write it as well). Getting in on al call for experts can be pathetically easy or incredably difficult, it depends on the spec lead. And then there is no process check or balance immediatly requiring them to listen to the experts in the group, so some groups have more sway in the spec and some have essentially none. The only real check and balance is political pressure ant the final approval vote.

Beyond that unless you are willing to pony up massive ammounts of time there really isn't much more for independent developers in the JCP. That's why I just let my membership expire.

May 17, 2003

TEST

test from clever cactus

About May 2003

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in May 2003. They are listed from oldest to newest.

March 2003 is the previous archive.

June 2003 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33