[
https://issues.apache.org/jira/browse/AXIS2-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652653#action_12652653
]
drosenbauer edited comment on AXIS2-4131 at 12/3/08 12:12 PM:
-------------------------------------------------------------------
I have been thinking about this further. Do you think there would be any
security repercussions to allowing the programmer or axis2.xml to override the
proxy settings?
For instance, a system owner may want to strictly define the proxy settings for
any Java applications running in his container. If we dynamically load some
class into his runtime environment (e.g. an Axis2 AAR file into a Tomcat
webapp), we might want to override the system owner's secure settings to either
avoid the proxy altogether or use a different proxy for nefarious purposes. If
we let the programmatic settings override the System Properties settings every
time, this is trivial. It would be nice if the system owner could define a
SecurityManager that would forbid updating the proxy.
Perhaps it would be prudent to add a flag in axis2.xml, or a relevant System
property, which would forbid programmatic overrides of the proxy settings. If
the flag is "true", System properties take precedence over all other settings
(for security purposes). If false (default), they would not. A system owner
worried about proxy security could simply turn on the preference either via a
-D system property or an axis2.xml configuration option.
What do you think?
(Edited for clarity on 12/03 @ 3:12 PM EST)
was (Author: drosenbauer):
I have been thinking about this further. Do you think there would be any
security repercussions to allowing the programmer or axis2.xml to override the
proxy settings?
For instance, a dynamically loaded class into some runtime environment (e.g. an
Axis2 AAR file into a Tomcat webapp) might try to define its own proxy settings
to override the System properties. It would not be possible for him to change
the System properties without a lot of work in an environment with a
SecurityManager, but with your change, it would be possible for him to override
the system owner's secure settings to either avoid the proxy altogether or use
a different proxy for nefarious purposes.
Perhaps it would be prudent to add a setting in axis2.xml, or a relevant System
property, which would forbid programmatic overrides of the proxy settings. If
the setting is "true", System properties take precedence over all other
settings. If false (default), they would not. A system owner worried about
proxy security could simply turn on the preference.
What do you think?
> Java http proxy settings override programmatic settings
> -------------------------------------------------------
>
> Key: AXIS2-4131
> URL: https://issues.apache.org/jira/browse/AXIS2-4131
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Devin Rosenbauer
> Priority: Minor
>
> My code:
> Options options = stub._getServiceClient().getOptions();
>
> HttpTransportProperties.ProxyProperties pp =
> new HttpTransportProperties.ProxyProperties();
>
> pp.setProxyName(proxyHost);
> pp.setProxyPort(proxyPort);
>
> options.setProperty(HTTPConstants.PROXY, pp);
> And in other code, not under my control:
> Properties p = System.getProperties( );
> if ( ( null != proxyHost ) && ( null != proxyPort ) )
> {
> p.setProperty( "http.proxySet", "true" );
>
> if ( null != proxyHost )
> p.setProperty( "http.proxyHost", proxyHost );
> if ( null != proxyPort )
> p.setProperty( "http.proxyPort", proxyPort );
> }
> This leads to an inexplicable failure to connect through the proxy, because
> the second bit of code is using different proxy settings that won't work in
> the Axis2 WS call. For now, I can work around this bug by clearing and
> re-setting the proxy values just before I call methods in my Stub class, but
> this is a bit silly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
