• Post Reply Bookmark Topic Watch Topic
  • New Topic

Problem with Java & SOAP response. cDATA tag is not written?  RSS feed

 
David Jhu Hoang
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everybody,

I have a problem with my Java code. I'm trying to write some data into a SOAP structure, and one of the fields is a password, which is possible it can comes with some extended ASCII characters, as usual.
One of the solutions I read, it's to write that password into a cData tag, so the content is not parsed and then it'd be able to be seen into a browser (in theory).
I'm wotking in local mode with Websphere Server (Liberty), and the output comes with cd cData Tag without problems. But when I promote the code to a WAS server, cData tag is not shown anymore.

Here's the Java code:



My output in local mode


<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/"><SOAP-ENV:Header/><soapenv:Body><RequestData><KeyStore><return>0</return><message>Operacion correcta.</message><password><![CDATA[xqixklkzsgklsxff]]></password></KeyStore></RequestData></soapenv:Body></soapenv:Envelope>


My output in Development Environment


<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tem="http://tempuri.org/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Header/><soapenv:Body><RequestData><KeyStore><return>0</return><message>Operacion correcta.</message><password>xqixklkzsgklsxff</password></KeyStore></RequestData></soapenv:Body></soapenv:Envelope>


My questions are:

- Using the cData Tag is really the best way for password string handling? I say this because I still have troubles with parsing when control ascii chars are returned
- Why cData Tag is removed?

Hope somebody can help

Thanks.
 
g tsuji
Ranch Hand
Posts: 697
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
- Why cData Tag is removed?

That I am not in a position to contradict your observations. It would be implementation-specific (see below for elaboration). But the main point however is that the serializations of form being with or without cdata section are semantically exactly the same - that is w3c-compliant xml processing trying to guarantee.

I'm wotking in local mode with Websphere Server (Liberty), and the output comes with cd cData Tag without problems. But when I promote the code to a WAS server, cData tag is not shown anymore.

Whatever precisely the mentioned servers are, the "normal" behaviour of the transformation in the code you're using is the one resulted by the latter setup. For the former, if that is really what happens can only be attributed as having some kind of sweetener on top of the normality. The normality I am talking is that when you call the method .newTransformer() without any argument, it is the identity transformation which is being used and implied. And the output won't contains any cdata section as a consequence.

- Using the cData Tag is really the best way for password string handling? I say this because I still have troubles with parsing when control ascii chars are returned

This statement I would say has a big dose of incorrectness. It can have its incorrectness in many directions. If your password has some "ascii control chars" and you want to put it in the xml in clear text and without further encoding, this can never happen and the resultant request or response would never be transported on the wire as it would be stopped well before as the xml is not well-formed. If you mean you put some "ascii control chars" inside a cdata section in this format <![CDATA[abc&#y07;def]]> (read y as x) where &#y07; (read y as x) is taken as an example, this is _not_ a control char inside the password. The password is actually xyz&amq;y07;uvw (read y as x, q as p) which is _not_ what you originally meant to have. In any case, cdata section is not the solution. Usually some kind of encoding is in fact used such as base64 encoded of it is used to be transmitted... and in that case there is even no issue with cdata section or not as it would be the same ascii characters. Apart from that, you may get some criticism that I am not doing as to transmitting password in the clear even with transport level security layer... But it is a very broad thing. ws-security and other related specs, plus that many diversed use cases to consider to warrant categoric statements often too lightly made.

In any case, I can nevertheless show you how you force a cdata section in the output of the transformation. It can be done, though I am not saying it resolves the true issue behind mentioned above.

First you construct an appropriate xslt document, say "id-cdata.xslt".

Then load it into the transformer...

(Maybe you break it up in a couple of lines for clarity...) Then you have thereby forced a cdata section on the password element. That is it.

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!