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

...tml&userid=SOMEUSER/TIGER@WW2&au_id...

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:

...tml&userid=SOMEUSER/L;8jb+6B@WW2&au_id...

Now, if I, the developer, do URL-escaping (procedure utl_url.escape by ORACLE) my textLabel correctly shows

...tml&userid=BMTIMA1/L%3B8jb%2B6B@WW2&au_id...

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.

asked 13 Nov '14, 16:19

dipr's gravatar image

dipr
1561323
accept rate: 0%


Hi Paul,

Yes this looks like a bug. I created a ticket in our issue tracking system.

Kind Regards,
Yalim

link

answered 14 Nov '14, 05:48

Yalim's gravatar image

Yalim ♦♦
2.8k5
accept rate: 22%

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 ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×10
×2
×1
×1

Asked: 13 Nov '14, 16:19

Seen: 797 times

Last updated: 14 Nov '14, 06:00


© Copyright Gerger 2017