MXUnit Eclipse plugin - Web Server Authentication (NTLM)?

[Goyuix]

Well, following the advice in a previous question I decided to kick
the tires on the Eclipse plugin, and so far I am not getting anywhere
really. Here are some things I have noticed:

When I try and search for a test, the plugin replies back "Unabled to
run ping method at facade..." telling to go and try running the
following page in the browser: https://<server>/mxunit/framework/RemoteFacade.cfc?wsdlmethod=ping
--- I can only assume it found that from my MXUnit preferences. So I
go and try to run it in the browser and sure enough, I get back a
bunch of whitespace and at the bottom: <wddxPacket
version='1.0'><header/><data><boolean value='true'/></data></
wddxPacket>

The server requires NTLM authentication, so I am guessing that is
probably problem number one. If I use the internal browser, which as I
understand it is basically just the COM object for Internet Explorer,
everything works just fine. Also of note, to connect to the outside
world I have configured a proxy and authentication credentials (which
allowed me to find & install the plugin so I know that is working).

Also, the plugin incorrectly told me to RemoteFacade.cfc?
wsdlmethod=ping - when I think it really just needs to be
RemoteFacade.cfc?method=ping

Last but not least, I got the following error. I recognize it and it
has bit me many times in the past - I need to add my companies Root CA
to the Java VM using the keytool.exe executable. I can work that, but
like the previous times I was faced with the error, it would be nice
to instead have a prompt that said "There was a problem with the sites
identity - Are you sure you want to connect?" and let me bypass the
error.

Exception message trying to connect to url
https://sii-dev-web.siinet.ms.northropgrumman.com/mxunit/framework/RemoteFacade.cfc?wsdl
is: ; nested exception is:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target



Thanks so much for your hard work and prompt replies to my previous
thread. The first thing that actually turned me on to this project was
that it seemed active still and I have certainly been proven right so
far!

[Goyuix]

Just a quick update, I did resolve the SSL certificate error and the
error I now get is "(401) Unauthorized" - which again points back to
NTLM issues.

Thanks

[billy]

Goyuix,

I'll let Marc verify, but I'm pretty sure it's an issue that the
plugin does not currently support NTLM authentication. We use NTLM
where I work and I was not able to get it working without allowing
the /mxunit/ install to allow anonymous access. For me, this was not
difficult to request because mxunit does not persist any sensitive
data. I'm pretty sure the issue is at the java network layer ... the
plugin uses AXIS to make the soap call to the remote facade and the
only java http client I have seen that supports NTML is HttpClient
(Jakarta). I'm not sure if HttpClient can be used for soap or not. The
good news is that the MXUnit Ant task uses HttpClient and should be
able to handle NTLM. I do need to test this, though.

Thanks for your patience. We'll look into it for sure. The plugin
should work for for tests on your local machine and on remote machines
that allow anonymous access.

bill

[Marc Esher]

Now this is a damn fine problem to have! And boy, are you gonna hate
my answer....

First, an explanation of why it behaves the way it does. this is not
an excuse, but it's an excuse, if you catch my meaning.

My not-an-excuse: when I think of unit testing, I think of developing
locally. period. I don't know why it's that way, but in my head,
developing locally is the only sensible way to develop. I think this
way because for 3 years I developed on a shared dev server and it
sucked, big time. When "New Consultant Guy" comes into work and writes
"while (true) true;" and the dev server keeps crashing every 3 minutes
for 2 hours straight... that tends to sour a man.

So, when I wrote the plugin, I wrote it only thinking of local
development. I didn't give any thought at all to the actual networking
side of things. It's disturbing, to look at the plugin code, and see
how many lines are devoted to the webservice call to the remote
facade. I remember when bill told me he was having authentication
issues over ntlm, my first reaction was "why the f**k are you trying
to connect to a non-localhost server?". my second reaction was "and
what the f**k is ntml?".

Shows you what I know.

OK, end of excuse. On to solutions.

I originally wrote the webservice calls in good old axis 1.x
Service.call() style because that's how I like it. no lame wsdl2java
codegen for me. and at the time of writing the plugin (summer/fall of
07), it had been a solid 3 years since i'd worked with java web
services. so my comfort was with axis 1.x. I checked out the axis 2
docs, it looked like a completely different product and I didn't want
to learn it, so I stuck with 1.x.

Sadly, I think the time has come to make the switch. It looks like you
can use Commons HTTP with 1.x, but unless i'm mistaken it looks like a
giant pain in the ass. And it looks like NTLM is supported natively
with axis 2 b/c it seems, if my reading is correct, that axis2 uses
commons http by default.

Now, the hard part really is figuring out how to intelligently handle
authentication within the plugin itself. because there are several
different types of authentication, and I know exactly 0 about any of
them, so I dont' really know the best way to proceed. Is it enough to
put some fields in the plugin for username/password? I wonder how
inside the plugin i'm supposed to know what authentication scheme to
use. And... I wonder if there's a better way than doing all of that.
This is what I have to find out. Ideally, the plugin would just plain
not have to worry about all of it; like, maybe it has access to some
kind of authenticated session in windows or something. I don't know...
but that would be nice.

The other problem here is that since I don't know jack about NTLM, I
don't know how to test it locally once I think I have a fix.

Bill, you have the "Services Explorer" plugin, right? I think that
comes with the web tools project. If you would be so kind, would you
see if you can access an NTLM-secured WSDL file using that plugin?
Because if you can, that must mean they're doing something dynamic
under the hood that handles all this without needing to prompt you for
credentials, and if that's the case, then maybe I can talk with those
folks and find out how they're doing it.

So, while I wish everyone would know the joy of developing locally, I
understand that isn't always possible. I want to get these
authentication problems worked out... it'll teach me a lot and it's a
fun challenge. But it's going to take a while.

Lame excuse #2 coming, Goyiux: I just had another daughter 2 weeks
ago, Bill's sellling his house, and we're preparing for a few
presentations right now and those preparations are taking up all of
(my) free time. I'm going to try to learn more about this ntml stuff
and see what i can whip up with axis2, but I fear it'll be some time
before I can spend the time required to get this into the plugin.

Now... were you to respond with "But Marc, I Goyiux am a Axis2 and
NTLM expert and here's all you need to know" well, then, that'd be
swell!

As I learn more about these things, I'll post back with my findings
and more questions.

Thanks.

Marc

[billy]

NTML is a beast to try to code! _I_ wouldn't attempt it. The nice
thing about HttpClient, is that it's API makes it very easy to handle
all the common forms of http authentication including NTML:

//MXUnit Ant Code snippet
if(!authMethod.equals("no_auth")){
List authPrefs = new ArrayList(3);
authPrefs.add(AuthPolicy.DIGEST);
authPrefs.add(AuthPolicy.BASIC);
authPrefs.add(AuthPolicy.NTLM);

this.client.getParams().setParameter(AuthPolicy.AUTH_SCHEME_PRIORITY,
authPrefs);
this.client.getState().setCredentials(AuthScope.ANY, new
UsernamePasswordCredentials(username, password));
this.doAuthentication = true;
}

Now, if AXIS had this or something similar built in (which I hope they
are aiming for), it would be fairly trivial to implement, just add
username and password to the mxunit preferences and execute
authentication when appropriate. If not, it will likely be an utter
bear to code.

bill

> >  Thanks- Hide quoted text -
>
> - Show quoted text -

[Marc Esher]

Thanks Bill. that's what I need to find out... if dealing with all the
various authentication mechanisms is as easy as delegating it to the
underlying client and simply pass in a username and a password and not
other auth-specific config options.

maybe i'll try first to see if i can with some ease switch axis 1.4 to
use commons http. if i can do that, i'll try to knock this bastard out
soon. if not, i'll try to figure all this out with axis2 because i
think it uses commons.

thanks G. you're a gentleman and a scholar and i'm proud to work with you.

Now where's my cohibas?

[Marc Esher]

I've made good progress here I think, although since I have no way of
testing it I'm kind of stuck until I can finish the code.

anyway, i got axis using httpclient and i'm able to send
usernames/passwords and supposedly under the hood axis will handle the
details of the authentication method.

Goyiux, are you familiar with subversion? If so, i could put a test
together and you could create a new project in eclipse that links to
the plugin source code. i'd have a junit test where you could add your
URL, username, and password, and then we could test to see if all this
code works wtihout me having to worry about the plugin details for
now.

If the code changes I made do work, the I can get them into the plugin
fairly quickly.

You want to try that?

Marc

[Goyuix]

Wow - I was impressed with your dedication before but you guys have
really stepped up to plate on this one. I am more or less familiar
with Subversion - in fact I went and http://mxunit.googlecode.com/svn/org.mxunit.eclipseplugin/trunk
and have pulled it into my Eclipse IDE. Unfortunately that is where my
ambition has ground to a halt. I am guessing I can use the Java
perspective and run a junit test of some sort - but I haven't ever
done that so any guidance would be appreciated!

On Feb 15, 1:36 pm, "Marc Esher" <marc.es...@gmail.com> wrote:
> I've made good progress here I think, although since I have no way of
> testing it I'm kind of stuck until I can finish the code.
>
> anyway, i got axis using httpclient and i'm able to send
> usernames/passwords and supposedly under the hood axis will handle the
> details of the authentication method.
>
> Goyiux, are you familiar with subversion? If so, i could put a test
> together and you could create a new project in eclipse that links to
> the plugin source code. i'd have a junit test where you could add your
> URL, username, and password, and then we could test to see if all this
> code works wtihout me having to worry about the plugin details for
> now.
>
> If the code changes I made do work, the I can get them into the plugin
> fairly quickly.
>
> You want to try that?
>

[Marc Esher]

GRRRRRRRR. I hate other people's free code sometimes.

i got it all working with basic auth, but with nt auth, it looks to me
like axis 1.4 doesn't understand that it needs to use NTCredentials
instead of UsernamePasswordCredentials on the underlying httpclient
auth scheme (see Goyiux... this morning I didn't know shit about shit,
and now i'm johnny auth. The best bugs are the kind that teach you a
lot).

So even though I read stuff where it says you should be able to use
axis 1.4 with ntlm, other stuff i found on the newsgroups from the guy
who wrote axis basically indicates that this "confusion" isn't fixed
in axis 1 but is fixed in axis2.

This sucks because it delays things a bit. It means I definitely have
to switch to axis2 now.

Oh well... can't use other people's 4 year old code forever i guess.
damn whippersnappers.

Updates to follow as I drink more beer.

[Marc Esher]

i figured out why i couldn't get it to behave properly with axis 1.4,
so that's resolved now.

goyiux, i've added some jar files and new code to the plugin, so
you'll need to do a team update.

then, to configure your build path, you'll need to right click on your
project, go to "build path", "configure build path".

that'll pop up a property sheet and there will be a "libraries" tab. go to that.

click "add jars"

navigate to the org.mxunit.eclipseplugin lib directory. there will be
a bunch of jar files in there. select them all and click OK on all the
property sheets

Then, back in the package explorer, open up
test/org.mxunit.eclipseplugin.actions.bindings
RemoteFacadeServiceTestCase.java

At the top, change the url, username, and password to what yo'ure trying to use.

then, right click in the window, select "run as", "Junit Test Case"

then tell me what you get.

I also put in an HttpClientTest in that directory that you could try
out, too, if that test case above doesn't work. for me, though, it
didn't matter what username or password I used.... i always got
through to the wsdl file even though it was supposed to be ntlm
protected.

Bill, you wanna give these steps a shot, too, with your stuff and see
if you are able to access the remote facade CFC by using your ntlm
credentials?

Also, moving to axis2 isn't possible now. the reason is that axis2
does not support rpc-encoded style services, and that's what this is.
We've been trying really hard to keep mxunit compatible with mx6.1,
and they didn't introduce doc-literal style webservice support until
mx7.

but i'm not sure that it matters anyway. now that i have a fuller
picture, i don't think axis2 will solve any problems that axis1 can't
handle.

Thanks guys.

Marc

[Marc Esher]

All,
I just released a new version of the plugin. It now has the
authentication stuff in there. You have to set the username and
password at the project level, though... not in the preferences.

select the project containing your tests, right click, select
properties, select mxunit. you'll see the username and password fields
at the bottom. plug in your credentials, click OK, and try running
tests.

It works for me with basic. I can't get ntlm auth working on my
machine but I Think that's a function of my machine and not the code,
since technically I'm not on any domain. So hopefully you guys have
better luck than I did.

Good luck!

Marc

[Goyuix]

Well, I tried a variety of things and the plug-in is still not working
for me. Still getting a 401 not authorized error.

Also, I tried running the junit tests but I think I either mis-
configured something or I am missing something. I did go download the
JUnit 4.4 jar, added it to lib, and then added it as a project library
(I didn't have the Run->Junit Test menu option before that). If I go
into the run dialog it complains that it cannot find test class
'RemoteFacadeServiceTestCase' in project 'org.mxunit.eclipseplugin' -
and despite various attempts at twiddling settings and fully-
qualifying names and such - I think I have just imported the project
all wrong from Subversion or something. I really hate to be a burden
on this - and I haven't done any real Java coding for years so there
is a ton of rust built up. I may look into a few other options such as
local-only testing through the plugin or maybe disabling NTLM security
on the tests directory and limiting connections by IP address or
something that would appease the network mafia.

Note: I added http://mxunit.googlecode.com/svn as a SVN repository,
then I expanded the tree to org.mxunit.eclipseplugin/trunk and did a
checkout with new project wizard. If you need more details I am happy
to provide them.

I am happy to continue testing the plugin, but I am afraid that I
would need a little more help in stubbing things out correctly - and
as you have mentioned previously the team has a lot going on right now
and I really don't want to be a burden when I don't feel like I am
contributing much. I am perfectly happy to table this for now and
maybe revisit it some time down the road.

Thanks for all you efforts thus far - I completely plan on continued
use of mxunit regardless of the the state of the plugin.

On Feb 18, 8:12 am, "Marc Esher" <marc.es...@gmail.com> wrote:
> All,
> I just released a new version of the plugin. It now has the
> authentication stuff in there. You have to set the username and
> password at the project level, though... not in the preferences.
>
> select the project containing your tests, right click, select
> properties, select mxunit. you'll see the username and password fields
> at the bottom. plug in your credentials, click OK, and try running
> tests.
>
> It works for me with basic. I can't get ntlm auth working on my
> machine but I Think that's a function of my machine and not the code,
> since technically I'm not on any domain. So hopefully you guys have
> better luck than I did.
>
> Good luck!
>
> Marc
>
> On Feb 15, 2008 4:59 PM, Goyuix <goy...@gmail.com> wrote:
>
>
>
> > Wow - I was impressed with your dedication before but you guys have
> > really stepped up to plate on this one. I am more or less familiar

> > with Subversion - in fact I went andhttp://mxunit.googlecode.com/svn/org.mxunit.eclipseplugin/trunk

[Marc Esher]

real quick, just one thing: you should only need to decrease the
security on the remotefacade.cfc file. you could even try just turning
it down to basic instead of using ntlm. you won't need to decrease any
permissions on the test directories or any other code.

best,

marc

[Marc Esher]

Also, Goyiux, please make sure you're using ntlm v1 and not v2. i do
know that v2 is not supported in axis.

Before I investigate this any further, Bill, can you see what you get
when you try out the code on your ntlm-protected stuff?

and i'm going to see if one of the network dudes at work can get me
set up properly so that I can confirm I have a correctly configured
ntlm environment, which will help me test this thing and see if
there's any other stones unturned.

Marc

On Feb 18, 2008 1:32 PM, Goyuix <goy...@gmail.com> wrote:
>

[billy]

Marc,

Do you think we need to supply the auth realm; that is, the NT Domain
in the project config? I got a 401 and thought that maybe the domain
might not be getting to the authorization logic. Just a thought ...

bill

> > Note: I addedhttp://mxunit.googlecode.com/svnas a SVN repository,

> ...
>
> read more »- Hide quoted text -

[Marc Esher]

the domain needs to be in the username, like mydomain\myuser.

in axis, that's how you do it. then, under the hood, it parses out the
domain name and passes that to the NTCredentials object in httpclient.

[M Steele]

I'm new to MXUnit, and have encountered the same problem "Could not
connect to facade URL" on my localhost (running CF8) with the
following console error:

Exception message trying to connect to url

http://localhost:8500/mxunit/framework/RemoteFacade.cfc?wsdl is:
(403)Forbidden

However, when I type in the URL mentioned in the eclipse error:

http://localhost:8500/mxunit/framework/RemoteFacade.cfc?wsdlmethod=ping

I get the CFAdmin login, and after logging in the cfcomponent docs are
displayed for RemoteFacade.cfc

However, if I put an '&' between the wsdl and the method parameter:

http://localhost:8500/mxunit/framework/RemoteFacade.cfc?wsdl&method=ping

then I get back the wddx packet with the boolean value. Without
checking out the eclipse plugin code, is this just an error in the
output of the message or is this actually what is being called by the
plugin?

[Marc Esher]

If you go to administrative tools, local security policy, security
options, and then scroll down till you find "network security: LAN
Manager authentication Level", what option is elected in the dropdown?
Tell me if your option is the same as the one in the attached
screenshot.

Also, the error message without the ampersand is just a weirdo bug i
haven't figured out yet. for me, the error message has the ampersand,
for some folks it doesn't show up. it's irrelevant, though, because
the actual code has nothing to do with executing the URL that way...
it's an entirely different mechanism.

Also, just make sure you're sending the right username/password in the
project properties, and make sure that if you're using ntlm, you're
sending the username in the form of domain\username.

Marc

[Goyuix]

Having had similar issues, I thought I would throw in my client
settings here as well - and also note that I never actually got the
plugin to work with NTLM in the office (and never tried elsewhere)....

My Group Policy setting was: "Send LM & NTLM - use NTLMv2 session
security if negotiated". I may try switching it and see what happens,
though I can't really guarantee I can leave (or even modify) that
setting as it might be forced down from the domain group policy.

G

On Feb 29, 3:16 pm, "Marc Esher" <marc.es...@gmail.com> wrote:
> If you go to administrative tools, local security policy, security
> options, and then scroll down till you find "network security: LAN
> Manager authentication Level", what option is elected in the dropdown?
> Tell me if your option is the same as the one in the attached
> screenshot.
>
> Also, the error message without the ampersand is just a weirdo bug i
> haven't figured out yet. for me, the error message has the ampersand,
> for some folks it doesn't show up. it's irrelevant, though, because
> the actual code has nothing to do with executing the URL that way...
> it's an entirely different mechanism.
>
> Also, just make sure you're sending the right username/password in the
> project properties, and make sure that if you're using ntlm, you're
> sending the username in the form of domain\username.
>
> Marc
>

> On Fri, Feb 29, 2008 at 4:12 PM, M Steele <m_steel...@yahoo.com> wrote:
>
> > I'm new to MXUnit, and have encountered the same problem "Could not
> > connect to facade URL" on my localhost (running CF8) with the
> > following console error:
>
> > Exception message trying to connect to url
> > http://localhost:8500/mxunit/framework/RemoteFacade.cfc?wsdlis:
> > (403)Forbidden
>
> > However, when I type in the URL mentioned in the eclipse error:
>
> > http://localhost:8500/mxunit/framework/RemoteFacade.cfc?wsdlmethod=ping
>
> > I get the CFAdmin login, and after logging in the cfcomponent docs are
> > displayed for RemoteFacade.cfc
>
> > However, if I put an '&' between the wsdl and the method parameter:
>
> > http://localhost:8500/mxunit/framework/RemoteFacade.cfc?wsdl&method=ping
>
> > then I get back the wddx packet with the boolean value. Without
> > checking out the eclipse plugin code, is this just an error in the
> > output of the message or is this actually what is being called by the
> > plugin?
>
>
>

> ntmlsettings.jpg
> 318KViewDownload

[Marc Esher]

hey guys, i hate to admit defeat but i'm 100% certain I wont' be able
to get this working with ntlmv2, and i'm only slightly less certain
that despite my best learnings i'm not having much luck getting it
going with ntlmv1, either.

as a compromise, would it be possible for you to do this:

1) on your server, set up a new virtual site or directory. have that
site use basic authentication
2) create a new file in that site called RemoteFacade.cfc
3) make the contents of that file:

<cfcomponent extends="mxunit.framework.RemoteFacade">

</cfcomponent>

best,

marc

[Goyuix]

Wow... the setting actually stayed after a reboot... but as you said
in your post - it really didn't matter as it didn't work.

I will plan on seeing if I can convince the powers that be to allow no-
auth and a restricted set of IP addresses to connect to the
remotefacade.cfc "page" and see if that clears everything up. From
what I have read and peeking into the code, it appears that exposing
this one file should do it - I shouldn't need to expose every test
etc....

Thanks for working and researching this so much. You guys rock.

G

[billy]

For what it's worth, I was able to convince the folks at work to open
up mxunit install with the reasoning that (1) it does not persist any
business or sensitive information (has no db), and (2) there is not,
in practice, any direct user interaction with the framework or
runners. The only user interaction is really with the examples or the
experimental blaster and generator.

bill