In custom properties at project level I observed that when I provide the value for the Password as a variable, it shows as hidden (****)
However when I run the request using the variable I could clearly see the password value in the RAW Request.
This sometimes makes me feel hesitant when I am wrapping the project and sending it to someone else to run it or creating regression which everyone can see.
I expect that if user intetionally pick to encrypt or hide the password, it should not be visible anywhere. Not even from the raw request.
Let me know what you think or if there is any better way to hide it.
In your scenario, I feel the behavior of raw request (I could clearly see the password value in the RAW Request) is an acceptable and expected one! The raw request is the non formated actual request sent to the server from SoapUI, which serves mutliple purpose as in tracking the request, debugging the service behavior etc., You could better remove the credentials an share to your peers if needed; in case if the credentials are much confidential.
Also, we might not worry about this option if we are passing the service requests with Sessions/ Authentication tokens, instead of passing passwords directly. Finally to answer your question I don't think there is a feature in SoapUI to hide passwords everywhere - even in raw request; though if we try tweaking through event handlers. Please correct if you have any such options!
Ok, in my case and I am sure in lot of other cases, one needs to provide password in soap header where it becomes visible. By having it as custom property makes it easy to maintain for entire project. When we create a variable with name as PASSWORD the soapUI kind of creates false impression by showing it with "*****" and double clicks makes it visible there.
Are there other best practices handling this type of scenario?
Also is there a feature to may be hide the Raw section (may be I am getting into permissions/authorization here)
Sometimes password management is challing, specially when you need different users with different authorizations and you want to build something for production and say may be share with customer or something outside the company
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.