|
I'm using html renderer to access an ORACLE Reports sever. In the process the url ist constructed, and displayed in a textLabel, to see what I compiled. If I use the credentials SOMEUSER with password TIGER all is well: The string section is both found in my debug textLabel and on the wire (checked via Firefox Firebug). However if the password contains forbidden URL characters like ; and + the application will fail, because both my textLabel and the firebug trace show the password to be unmodified: Now, if I, the developer, do URL-escaping (procedure utl_url.escape by ORACLE) my textLabel correctly shows BUT on the wire firebug finds ...tml&userid=BMTIMA1/L%253B8jb%252B6B@WW2&au_i... clearly a double escape, where the % of my escaping have been esacped a second time (=> %25), thereby ruining the passwort. So neither the verbatim version can connect (because of unaltered, illigale characters in the url) nor can the escaped verion, because the url renderer(?) likes to escape %, but not the ohter forbidden characters! I think this is a bug: Either let the url constructing developer do all the work and don't postprocess anything, or do a complete url escaping. |
|
Hi Paul, Yes this looks like a bug. I created a ticket in our issue tracking system. Kind Regards, While my answer did convince you of a formspider bug, I want to avoid redirecting your company's ressources to hunting the bug in vain: I've been thinking about it, trying to find an error in my reasoning: Assuming that the client's browser (and not the java code inside tomcat) is resolving and accessing the URL, can it be that the browser is doing the encoding, for whatever reason, of just the %, leaving all other illegal url characters alone? If that is true, your coude might be "innocent". But we'd still need a way to get around the problem...
(14 Nov '14, 05:54)
dipr
It's possible. Can't tell unless we look further. I know this may not be possible with the reports server but one way to avoid the issue is not to send user name and password in the URL. It would be better to send a randomly generated token in the URL, which gets resolved to a user name and password in the server after being validated. Is this possible?
(14 Nov '14, 05:59)
Yalim ♦♦
|
