Open GoogleCodeExporter opened 9 years ago
+1 for the issue. A fix definitely go into trunk.
I have a few questions though -
1. Why not use targetUrl.getUserInfo instead of targetUrl.getAuthority. It will
save
us from unnecessary indexOf operation.
2. Does the getUseProxyServer method in this class needs to change too? Right
now it
returns a ProxyHost. The way it is written (indexOf ":" etc), it will never
work for
user:pswd@server.com kind of proxy url's.
3. What kind of test cases do we expect for this enhancement?
I am waiting for answers and almost ready with an untested patch.
Paul, your insights please.
Original comment by avl...@gmail.com
on 10 Aug 2009 at 6:58
I don't know too much about proxying requests so I can't really give feedback
on the
code here, but am happy to accept a well tested patch with test cases.
Original comment by tuc...@gmail.com
on 10 Aug 2009 at 11:54
Thanks for the follow up guys.
1) getUserInfo is the more logical choice. I'm not 100% familiar with these
classes
yet.
2) You're right, however I believe this is a separate issue. The proxyHost
that is
passed to this method is separate from the the targetUrl.
3) At the very least:
+ proxy a regular request to a server with authentication
+ proxy a request that already has basic authentication configured to a server
with
authentication.
Original comment by psa...@tibco.com
on 12 Aug 2009 at 6:13
Original comment by avl...@gmail.com
on 6 Jan 2010 at 7:11
Adding a patch for this enhancement. Basic user authentication scheme can now be
supported. This means that once this patch has been applied, the underneath
would
work as expected -
<rule>
<from>/some-path-in-app1</from>
<to type="proxy">http://user:password@internal.app2.com/</to>
</rule>
The patch is untested. I'll attach a revised one with test cases shortly.
Original comment by avl...@gmail.com
on 13 Feb 2010 at 9:18
Attachments:
Original issue reported on code.google.com by
psa...@tibco.com
on 7 Aug 2009 at 1:43