Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 135838 - I can make refresh JAX-RPC web service client fail with HTTP BASIC Authentication
I can make refresh JAX-RPC web service client fail with HTTP BASIC Authentica...
Status: VERIFIED FIXED
Product: serverplugins
Classification: Unclassified
Component: Sun Appserver 9
6.x
All Windows Vista
: P1 (vote)
: 6.x
Assigned To: Vince Kraemer
issues@serverplugins
61fixes3-fixed
:
Depends on: 142048
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-26 21:05 UTC by rdelaplante
Modified: 2008-09-04 13:22 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
possible fix (783 bytes, text/plain)
2008-06-11 23:16 UTC, Lukas Jungmann
Details
proposed fix for o.n.core - feel free to review and reuse (15.03 KB, text/plain)
2008-06-20 17:27 UTC, Lukas Jungmann
Details
NB 6.1 fixes backout log (3.80 KB, text/plain)
2008-07-29 17:23 UTC, rbalada
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rdelaplante 2008-05-26 21:05:16 UTC
Right click the web service client and select refresh.  It asks me URL, I accept the default.  It asks if I want to
accept SSL certificate.  I click Yes.  It asks for HTTP username and password.  I click cancel.  It said something about
 an error, HTTP 401 I think?  I expected that.


Now right click the web service client again, refresh, accept default URL, accept the SSL certificate, and it will not
prompt for a username/password again.  Instead it will go straight to the same error message.
Comment 1 rdelaplante 2008-05-26 21:06:17 UTC
Even after restarting the IDE it will not prompt me for username/password anymore.  Why? Now I can no longer do
development on my project.  
Comment 2 rdelaplante 2008-05-26 21:10:39 UTC
I deleted the web service client and tried to create a new one.  It asked if I would like to accept the SSL certificate,
I said yes, and it did not ask me for username/password.  It failed to load the WSDL.   I am *really* stuck now.

I tried the same URL in a web browser.  It asked me to accept SSL certificate, and for a username/password.  When I
entered the correct username/password, it displayed the WSDL. 
Comment 3 rdelaplante 2008-05-26 21:14:41 UTC
Changing to P1 because I can't find a workaround
Comment 4 Lukas Jungmann 2008-05-26 21:32:02 UTC
Can you try to download the WSDL, use from local WSDL option in new ws client wizard and see if it helps, please?
Comment 5 rdelaplante 2008-05-26 22:20:24 UTC
I saved the WSDL as a file and added a web service client to my project. I was surprised that it worked because it
references a separate xsd file (generated by JAX-WS).   The output window in NetBeans looked like this:

wscompile-init:
Created dir: D:\dev\FolioService\FolioServiceClientDemo\build\generated\wsclient
Created dir: D:\dev\FolioService\FolioServiceClientDemo\build\generated\wsservice
Created dir: D:\dev\FolioService\FolioServiceClientDemo\build\generated\wsbinary
FolioService-client-wscompile:
Copying 1 file to D:\dev\FolioService\FolioServiceClientDemo\build\generated\wsclient\wsdl
BUILD SUCCESSFUL (total time: 2 seconds)

However in my code window of the servlet that uses the service, many lines have the red error underline.  When I type in
the package name that contains the client, no classes are shown.  When I look in the files tab at the project's build
directory I can see the generated files.   Restarting the IDE didn't help, it still shows up with errors everywhere.  I
was able to build the project with no errors though. 
Comment 6 Roderico Cruz 2008-06-02 06:55:06 UTC
Ryan, Is this the scenario that is described in your blog:
http://www.ryandelaplante.com/rdelaplante/entry/ssl_and_http_basic_authentication

If not kindly attach or send me (roderico.cruz@sun.com) the sample projects.

Thanks.
Comment 7 rdelaplante 2008-06-09 20:05:42 UTC
No that blog entry is not what I was doing.  It talks about JAX-WS, and this bug is with JAX-RPC.

I can't give you my closed source source code.  I can tell you that there is a JAX-RPC web service deployed to GlassFish
secured with SSL and HTTP BASIC authentication.   It was developed and deployed with NetBeans into SJSAS 9.1 UR2.   I
created a new web project to write a client application that would use the service.
Comment 8 Jaroslav Pospisil 2008-06-11 10:03:03 UTC
The red lines in servlet window are most probably caused by same reason as issue 135841. If so, code is still
compillable, despite the errors . Fact, that scenario works locally means there's workaround, so it's not definitely P1.
Decreasing priority to P2.
Comment 9 rdelaplante 2008-06-11 14:39:27 UTC
This ticket is about NetBeans caching the username/password when retrieving WSDL to generate a web service client until
you restart NetBeans.  If you enter an invalid username/password or press cancel, it will not prompt you again when
trying to regenerate a web service client. It just fails every time. 

Yes I would agree the code window red lines is issue 135841).
Comment 10 Lukas Jungmann 2008-06-11 23:15:58 UTC
> This ticket is about NetBeans caching the username/password when retrieving WSDL to generate a web service client until
you restart NetBeans.

Looks like attached patch solves this (at least for me), feel free to reuse.
Comment 11 Lukas Jungmann 2008-06-11 23:16:52 UTC
Created attachment 62705 [details]
possible fix
Comment 12 rdelaplante 2008-06-11 23:20:50 UTC
Will this patch also work for non-SSL web services?  It looks specific to https/SSL.  Thanks
Comment 13 Lukas Jungmann 2008-06-12 01:08:00 UTC
looks like not :( I'll try to dig into this a bit more in the morning...
Comment 14 Lukas Jungmann 2008-06-13 09:56:52 UTC
Well, actually it's JDK who's caching user credentials if some http/https resource requires BASIC authentication (same
issue appears when xml retriever is getting WSDL for JAX-WS client and perhaps also in some other scenarios)

One possibility to solve this could be introducing some kind of NB specific java.net.Authenticator but the question is
how this would influence the behaviour of the rest of the IDE if would introduce something what would be available globally.

I recall the was some user auth. related issue on the glassfish node in services tab (if admin's credentials were
invalid the dialog was poping up ~10-15x, sometimes forever), so another possibility could be to try to check how it's
solved in glassfish plugin[1]. That could give us some clue how we could solve this in websvc area.

[1] see: org.netbeans.modules.j2ee.sun.ide.editors.AdminAuthenticator in j2ee.sun.appsrv module
Comment 15 Lukas Jungmann 2008-06-20 15:36:24 UTC
back from the vacation...

problem seems to be in org.netbeans.core.NbAuthenticator which overrides default java.net.Authenticator instance from
the JDK in the way that user is never asked for credentials if BASIC auth is required by the server for any
http/https/??? connection - that's a regression against 5.x.x releases and an adoption blocker in moving to the 6.x
versions of the IDE => P1

I'll attach possible patch for the NbAuthenticator class later today ;-)
Comment 16 rdelaplante 2008-06-20 15:42:16 UTC
Great, I'm glad to see this one finally fixed.  You mentioned that the code *never* asks for HTTP BASIC
authentication... For me, it does ask me for username/password the first time I try.  After I press OK or cancel it
won't ask for username/password again until I restart the IDE.  I seem to remember struggling through this once or twice
where even an IDE restart didn't help.  Hopefully these issues are related.
Comment 17 Lukas Jungmann 2008-06-20 16:32:56 UTC
yes I've mentioned never, steps follow - checked several times in 5.5.1 FCS, 6.0.1 FCS, 6.1 FCS + official patches,
nightly builds of 6.5:

-start the IDE, create a web project with a web service secured with BASIC auth (optionally running over HTTPS) and run
it (exact steps in Rayn's blog - see desc7 - thanks for that!)

-start another instance of some other IDE with clean userdir
-get all updates (iff applicable)
-register glassfish in the IDE (*)
-install JAX-RPC plugin from the UC (iff applicable)
-create new java application
-create new JAX-RPC websvc client for the service created previously
-finish the new websvc client wizard

=> in 5.5.1 this works, in any later version it doesn't work unless I do something related to glassfish, see bellow


If I skip a step marked with (*) then I'm never asked for credentials, if I don't skip it then
org.netbeans.modules.j2ee.sun.ide.editors.AdminAuthenticator seems to be set as default java.net.Authenticator for the
IDE somehow (it's enough to expand servers node in services tab) and I'm asked for the credentials in the same way as
you - adding Vince on cc - so there are actually two issues - first, I'd say more serious, in NbAuthenticator, second in
AdminAuthenticator which seems to be caching incorrect credentials (perhaps as a result of a fix for constantly poping
up auth dialog when there wasn't set admin's pwd in the IDE - I don't remember details here) according to desc1
Comment 18 Lukas Jungmann 2008-06-20 17:27:23 UTC
Created attachment 63174 [details]
proposed fix for o.n.core - feel free to review and reuse
Comment 19 Lukas Jungmann 2008-06-23 13:08:31 UTC
After discussion with Jirka re-assigning to myself...
Comment 20 Lukas Jungmann 2008-06-23 16:58:18 UTC
fixed the core part in:

http://hg.netbeans.org/main/rev/9d1eab5b6857
http://hg.netbeans.org/main/rev/a6a199f24265
http://hg.netbeans.org/main/rev/d70e254a1aff

moving to GlassFish plugin to fix the rest of the issue there.

The condition on line 77 in AdminAuthenticator seems to be wrong since "displayed" can never get again to the "false"
state after it's set to "true"...
Comment 21 Vince Kraemer 2008-06-23 21:26:16 UTC
I think I was able to reproduce the issue and resolve it.

http://hg.netbeans.org/main/rev/c5a1ad856b70

Please reopen if there is still a problem
Comment 22 rdelaplante 2008-06-23 21:29:46 UTC
That's great, thank you.  I can't test until it's available for production use. I see you've decided to make this fix
available in Fall/Winter (NB 6.5) instead of NB 6.1 Patch 2 (next week).  Is that because the fix is so close to patch 2
release date? 
Comment 23 Lukas Jungmann 2008-06-23 21:51:10 UTC
Unfortunately it's too late to include this in patch2. Anyway marked this for inclusion in patch3 but I'm not sure about
its release date
Comment 24 Vince Kraemer 2008-06-23 21:58:06 UTC
I don't make that decision...  I check code into the trunk.  pushing it into a patch release can only happen AFTER the
issue has been verified as resolved... I don't understand why you cannot do that verification, but I think there are a
couple people on the team (like jungi) who will be able to verify it.  Once it is verified, it may go into a patch...
though I doubt that it will be patch 2.  There is already a patch three in the works
http://wiki.netbeans.org/NetBeans61Patch3Plan.
Comment 25 Quality Engineering 2008-06-24 04:27:01 UTC
Integrated into 'main-golden', available in NB_Trunk_Production #278 build
Changeset: http://hg.netbeans.org/main/rev/9d1eab5b6857
User: Lukas Jungmann <jungi@netbeans.org>
Log: IZ #135838: I can make refresh JAX-RPC web service client fail with HTTP BASIC Authentication - core
Comment 26 Lukas Jungmann 2008-06-25 14:44:59 UTC
original issue is fixed and current state is much better than it was although there are still some minor issues which I
filed separately - see issue 138222 and issue 138232

Marking this verified and ready for patch3...
Comment 28 pgebauer 2008-07-29 12:28:44 UTC
The bugfix cannot be delivered via AUC. It will be most likely rolled back. ( Please see issue 142048 )
Comment 29 rbalada 2008-07-29 17:22:00 UTC
I've backed out all four changesets due to new dependency on issue 142048, which blocks resolution of this issue for NB
6.1 fixes codeline. Changed status whiteboard back to 61fixes3-candidate.
See attached backout log for information about revisions.

Comment 30 rbalada 2008-07-29 17:23:12 UTC
Created attachment 65966 [details]
NB 6.1 fixes backout log


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo