This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | I can make refresh JAX-RPC web service client fail with HTTP BASIC Authentication | ||
---|---|---|---|
Product: | serverplugins | Reporter: | rdelaplante <rdelaplante> |
Component: | Sun Appserver 9 | Assignee: | Vince Kraemer <vkraemer> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, jpospisil, jrechtacek, jungi, pjiricka, rdelaplante, sustaining, vkraemer |
Priority: | P1 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | Windows Vista | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 142048 | ||
Bug Blocks: | |||
Attachments: |
possible fix
proposed fix for o.n.core - feel free to review and reuse NB 6.1 fixes backout log |
Description
rdelaplante
2008-05-26 21:05:16 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. 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. Changing to P1 because I can't find a workaround Can you try to download the WSDL, use from local WSDL option in new ws client wizard and see if it helps, please? 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. 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. 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. 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. 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). > 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.
Created attachment 62705 [details]
possible fix
Will this patch also work for non-SSL web services? It looks specific to https/SSL. Thanks looks like not :( I'll try to dig into this a bit more in the morning... 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 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 ;-) 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. 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 Created attachment 63174 [details]
proposed fix for o.n.core - feel free to review and reuse
After discussion with Jirka re-assigning to myself... 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"... 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 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? 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 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. 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 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... I've ported the bugfix into release61_fixes repository. http://hg.netbeans.org/main/rev/9d1eab5b6857 ported to http://hg.netbeans.org/release61_fixes/rev/b9de4829cd61 http://hg.netbeans.org/main/rev/a6a199f24265 transplanted to http://hg.netbeans.org/release61_fixes/rev/cf48733b5d7d http://hg.netbeans.org/main/rev/d70e254a1aff transplanted to http://hg.netbeans.org/release61_fixes/rev/926915e78e70 http://hg.netbeans.org/main/rev/c5a1ad856b70 transplanted to http://hg.netbeans.org/release61_fixes/rev/5718b128743e The bugfix cannot be delivered via AUC. It will be most likely rolled back. ( Please see issue 142048 ) 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. Created attachment 65966 [details]
NB 6.1 fixes backout log
I've re-integrated the changesets into release61_fixes repository. Those changesets got into release61_fixes repository in this way http://hg.netbeans.org/main/rev/9d1eab5b6857 ported to http://hg.netbeans.org/release61_fixes/rev/38ca9c63f408 http://hg.netbeans.org/main/rev/a6a199f24265 transplanted to http://hg.netbeans.org/release61_fixes/rev/ffcf433e58b7 http://hg.netbeans.org/main/rev/d70e254a1aff transplanted to http://hg.netbeans.org/release61_fixes/rev/5bcbdf2f6476 http://hg.netbeans.org/main/rev/c5a1ad856b70 transplanted to http://hg.netbeans.org/release61_fixes/rev/683ff76d1a53 |