You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Ryan Hoegg <rh...@isisnetworks.net> on 2003/01/29 01:59:21 UTC
Authentication refactoring
I committed my authentication refactorings. They did not include any
changes to the SunSSLTransportFactory, as it was too new for me to get
comfortable with. (translation: I didn't take the time to understand it
fully).
The gist of it is that setBasicAuthentication on XmlRpcClient has been
deprecated. I added a setBasicAuthentication method on
DefaultXmlRpcTransport and LiteXmlRpcTransport. I also made some
modifications to execute(String, Vector) and executeAsync(String,
Vector, AsyncCallback) so that existing users of
XmlRpcClient.setBasicAuthentication aren't unpleasantly surprised.
As I mentioned in an earlier e-mail and the javadoc, the credentials
passed to XmlRpcClient.setBasicAuthentication are only used in the
versions of execute and executeAsync that were around in 1.1. They are
discarded in all other overloads.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: Authentication refactoring
Posted by Andrew Evers <an...@redwood.com>.
> I committed my authentication refactorings. They did not include any
> changes to the SunSSLTransportFactory, as it was too new for me to get
> comfortable with. (translation: I didn't take the time to understand it
> fully).
It's a bit 'magic' due to the way Sun decided to do a few things ;) It's
all setting static variables (how very object-oriented we all cry).
> The gist of it is that setBasicAuthentication on XmlRpcClient has been
> deprecated. I added a setBasicAuthentication method on
> DefaultXmlRpcTransport and LiteXmlRpcTransport. I also made some
> modifications to execute(String, Vector) and executeAsync(String,
> Vector, AsyncCallback) so that existing users of
> XmlRpcClient.setBasicAuthentication aren't unpleasantly surprised.
The stuff on the transports themselves will work, however the changes
to the transport factory won't. I've just extended the properties concept
for transport factories so that it is possible to set a property on an
already
created factory (although the factory may ignore or veto the change). This
will let it work as long as new factories co-operate.
I should probably add getProperty(), getProperties() and removeProperty()
as well, but these are of much less use.
If you use the DefaultXmlRpcTransportFactory then properties are
set for both the http:// and https:// transports when setProperty is
called.
Andrew.
Re: Authentication refactoring
Posted by Andrew Evers <an...@redwood.com>.
> I committed my authentication refactorings. They did not include any
> changes to the SunSSLTransportFactory, as it was too new for me to get
> comfortable with. (translation: I didn't take the time to understand it
> fully).
It's a bit 'magic' due to the way Sun decided to do a few things ;) It's
all setting static variables (how very object-oriented we all cry).
> The gist of it is that setBasicAuthentication on XmlRpcClient has been
> deprecated. I added a setBasicAuthentication method on
> DefaultXmlRpcTransport and LiteXmlRpcTransport. I also made some
> modifications to execute(String, Vector) and executeAsync(String,
> Vector, AsyncCallback) so that existing users of
> XmlRpcClient.setBasicAuthentication aren't unpleasantly surprised.
The stuff on the transports themselves will work, however the changes
to the transport factory won't. I've just extended the properties concept
for transport factories so that it is possible to set a property on an
already
created factory (although the factory may ignore or veto the change). This
will let it work as long as new factories co-operate.
I should probably add getProperty(), getProperties() and removeProperty()
as well, but these are of much less use.
If you use the DefaultXmlRpcTransportFactory then properties are
set for both the http:// and https:// transports when setProperty is
called.
Andrew.