Let me give you more.
We have a provisioning system that communicates with another system (from another company, they gave us a WSDL we generated the client from it).
For a year everything has worked fine. Then they issued us a new password. The old password had no special characters in it (xml special characters) only characters and ordinals and dots.
eXAMPLE: r8.KLu90tY
The new password has special characters in it. When I tried to use our system to talk to theirs I get a 403 error (Forbidden).
I have called the other company and they confirmed the new password was correct. Multiple tries have failed.
I called them and asked them to set the password to one with no special characters and everything went back to working.
So, my theory is that the client classes generated from a SOAP WSDL do not (by default) do character escaping.
I am trying to confirm this with someone who knows more about the SOAP protocol, WSDLs, and WS than I do.
If soap classes generated from a WSDL are supposed to do character escaping (by some spec), then I can tell the other company about the problem and we don't need to do anything.
We are the only user of their software for this product.
If the strings need to be escaped in our code then OK, I can do that. Actually, I did not write this code, I have was awarded Thursday morning and I have been trying to figure it out.
I do not have a lab to
test this in as this is their standby production system.
So, I am trying to determine which side the problem is on so I can not look to stupid to my boss.
I cannot just write a new class an deploy it to our server to test because that is against policy. It would have to be an authorized deployment.