Skip to content
This repository has been archived by the owner on Jan 30, 2019. It is now read-only.

WS-Security Erasing SOAP Fault Body #1690

Open
glassfishrobot opened this issue Jan 14, 2015 · 3 comments
Open

WS-Security Erasing SOAP Fault Body #1690

glassfishrobot opened this issue Jan 14, 2015 · 3 comments

Comments

@glassfishrobot
Copy link
Contributor

Using the version of Metro released included in Glassfish 4.1. The log indicates Metro/2.3.1-b419 (branches/2.3.1.x-7937; 2014-08-04T08:11:03+0000).

I have a SOAP v1.1 web service client with a simple security policy to include a UsernameToken with a plain text password in outbound requests. (No security header is expected in responses from the server.) This works correctly on successful requests, however when the server responds with a SOAP fault, by the time the message reaches my application code, it consists of only an empty SOAP Header and Body, with no content.

I used JAX-WS's built in HTTP transport logging to verify that I was receiving a proper SOAP Fault with the expected contents from the server. (Possibly relevant, the SOAP fault declared an unused SOAP v1.2 namespace as reported in #1486.) I wasn't able to do before-and-after dumps for the SecurityTube to confirm that was where the message contents were erased due to #1658 throws exception when processing SOAP fault"). However, when I removed the security policy and instead wrote a custom SOAP Handler in my application to insert the Security header in the request, the issue did not occur and the SOAP Fault successfully made it to my application code.

Environment

Glassfish 4.1

Affected Versions

[2.3.1]

@glassfishrobot
Copy link
Contributor Author

Reported by anowac01

@glassfishrobot
Copy link
Contributor Author

Was assigned to symonchang

@glassfishrobot
Copy link
Contributor Author

This issue was imported from java.net JIRA WSIT-1690

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant