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.
NB: 200805280004 OS: Ubuntu 8.04 JDK: 1.6.0_10 Suppose you have running Glassfish V2 with an "Access Manager". Create 2 web applications, one (WApp1) with a web service and some operation, one (WApp2) with a web service client on this operation. For the Server: 1. Invoke "Edit Web Service Attributes" on WS in WApp1 2. Check "Enable Message Level Security", choose SAML-SenderVouches, click OK and deploy the application For the Client: 1. Invoke "Edit Web Service Attributes" on WS in WApp2 2. Check "Enable Message Level Security", choose SAML-SenderVouches, click OK, deploy the application -> check "amconfig.xml" file (in Projects view, node WApp2>Configuration Files>amserver) -> check output window "WApp1 (run-deploy)" at the line "USERNAME_PASSWORD_PAIR" 3. Invoke "Edit Web Service Attributes" on WS in WApp2 again 4. Leave "Enable Message Level Security" checked, choose "UserNameToken", fill in some (random, for example) credentials 5. Choose SAML-SenderVouches from the combobox again 6. Click OK -> check "amconfig.xml" -> check the log at the line "USERNAME_PASSWORD_PAIR" The credentials you filled in during step 4 are now included in the "amconfig.xml" file. I think this behavior can cause a security vulnerability of the client-server solution generated by NB, as user's credentials are included in XML file and sent to the server in a situation they shouldn't be, which can cause problems when a security mechanisms are changed (correct me if I am wrong and close this issue as invalid if I am wrong). Resulting XML file. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ns2:AMConfig xmlns:ns2="h t t p : // identity.netbeans.org/access_manager_config_1_0"> <!-- note: line modified manually by http //--> <ProviderConfig type="WSC" name="NewWebServiceService"> <SecurityMechanism uri="urn:sun:wss:security:null:SAMLToken-SV"/> <UserPassSettings> <Username>joshis</Username> <!-- HERE //--> <Password>MyPa55w0rd</Password> <!-- AND HERE //--> </UserPassSettings> </ProviderConfig> </ns2:AMConfig> (I think the XML file should be regenerated whenever any change is made.)
I think this could be somehow related to issue 135811 - probably similar cause.
The amconfig.xml is really a local cache file used at design time to remember values entered by the user to avoid querying the server at design time. It shouldn't be packaged with the war file. I think that should be the fix for this issue. As a workaround, you can bring up the Project Properties dialog, go to the Build/Packaging tab and add the amconfig.xml as one of the file to exclude from the war file. Alternatively, you can also explicitly empty out the username and password fields in the UI.