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.
-have a project with webservice which wsdl imports some xsd (or generally any xml file accessible over the network which imports another xml) secured by basic auth -create new websvc client for that service -cancel the auth dialog which will pop up => cancel dialog pops up again for xsd imported from wsdl but it should not since I already canceled auth process in previous step
Are there steps that I can follow to reproduce this issue?
I think this one might be invalid but I'm not able to say it for sure. Will try to give an update later today
sorry, no update - there are still some issues in JAX-RPC support which are blocking me now from trying this... Will file them tomorrow
yup, reproduced, steps are as I described them at the very beginning of this issue, so for your convenience: 1) start glassfish from the commandline since IDE will have to be restarted several times during this exercise and we need GF instance to be running all the time to see the user impact of this issue 2) go to GF admin console Security->realms->file and add a user there - I used username: user, group: user, password: user Since nbms-and-javadoc build on hudson is unstable quite often, it has not been exceptional that for 4days in a week, you might want to build jaxrpc modules/nbms yourself in the following order: websvc.jaxrpc16, websvc.registry, websvc.jaxrpc and websvc.jaxrpckit - this is the only option if the build will be broken. If it will be only unstable then you can get nbms from UC at: http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/nbms/updates.xml.gz and in case the build will be stable you're a lucky man - you can get nbms from dev UC in the IDE (why all this overhead? see issue 146599 which was fixed recently) assuming you have JAX-RPC nbms already somewhere, so just install them all and restart the IDE (to avoid possible websvc related issues - there should not be any at this point but just in case) now: 3) register glassfish in the IDE 4) take attached project and deploy it 5) create new javaapplication 6) create new websvc client there: url will be: https://localhost:8181/SecuredService/SecureService?wsdl , switch client-style to JAX-RPC fill in a package name, finish the wizard 7) accept the certificate and use user/user for username/password 8) restart the IDE correct behaviour: 9) expand javaapp -> webservices references node 10) you may face exceptions reported in issue 146934 but they seems to be harmless, so just skip them 11) right-click on the ws client node, choose refresh client, fill https://localhost:8181/SecuredService/SecureService?wsdl in the dialog and ok 12) accept certificate 13) cancel auth dialog 14) cancel wsdl file download dialog -if steps 13-14 are done within 3s auth dialog will not appear again; 3s timeout here should be the same as in Java WebStart implementation of the java.net.Authenticator for this particular use-case (btw: there one can find interesting comment about why ~3s is "the right" value) buggy behaviour: 15) restart the IDE 16) switch to services view, do refresh on the GF node and expand some of them 17) switch back to projects view 18) expand javaapp -> webservices references node 19) you may face exceptions reported in issue 146934 but they seems to be harmless, so just skip them 20) right-click on the ws client node, choose refresh client, fill https://localhost:8181/SecuredService/SecureService?wsdl in the dialog and ok 21) accept certificate 22) cancel auth dialog (noticed different UI here?) 23) cancel wsdl file download dialog => auth dialog appears again but I did dismiss it in step 22 already Note that this is just simple scenario where WSDL file references only one document but those with more imports/includes are quite common, so imagine it like dismissing same dialog 5times in a row for one unintentional access to the file one wants to discard Since no request had been made to the server (see steps 13 and 22 where the requests were finally not done) there's also nothing in the server's log, the only interesting information printed to the IDE's log came after step 13: ... [exec] WARNING [org.netbeans.core.NbAuthenticator]: No authentication set while requesting https://localhost:8181/SecuredService/SecureService?wsdl [exec] WARNING [org.netbeans.core.NbAuthenticator]: No authentication set while requesting https://localhost:8181/SecuredService/SecureService?xsd=1 ... Why it works fine for JAX-WS but not for JAX-RPC? That's also a good question. The scenario here is based on issue 135838 filed by external user
Created attachment 69668 [details] project with ws with BASIC/SSL auth. after deployment
two minor things I've forgotten: -the fact that wscompile after step 6 fails is not important for this issue (it's known fact that JAX-RPC cannot consume JAX-WS service using default settings, AFAICT) -once Authenticator.setDefault(...) call happens in a GF plugin all NB modules installed in the IDE will become affected by this issue when they will try to access some remote file secured by basic auth. Workaround for them seems to be to instead of relying on default Authenticator functionality try to set request headers on the URLConnection object (ie. sth like conn.setRequestProperty("Authorization", "Basic " + Base64.encode(username:password)) should do the trick) although I haven't tried it for this particular scenario
http://hg.netbeans.org/main/rev/59beabe3ccaa
Thanks, v.