How to implement HTTP Authorization? about fxmlrpc

[JoakimLofgren]

Using Guzzle as transport you might do something like:

$guzzle = new \GuzzleHttp\Client([
    'defaults' => [
        'auth' => ['username', 'password']
    ]
]);
$transport = new \fXmlRpc\Transport\Guzzle4Bridge($guzzle);
$client = new \fXmlRpc\Client('http://endpoint.com', $transport);

I haven't tried it, but that should be the gist of it.

[sagikazarmark]

The point is (as I said earlier) I don't now about the transport, only the injected Client.

[JoakimLofgren]

Ah right, then I guess you'd have to make a pull request to implement a getter for the transport property.

[sagikazarmark]

Probably yes. However I am not sure if opening the API is a good idea.

[sagikazarmark]

That would also mean that I should put it in the interface as well. Which should be thought wisely.

[lstrojny]

We could either add support for certain authentication variations to the bridges or, that is what I would prefer, leave it up to the client to the HTTP level authentication. But I will easily be convinced otherwise in case it works nicely within the bridges.

[sagikazarmark]

The PR #15 is related to this. HttpTransportInterface has option for modifying headers which is basically what we need for http authentication. I think it is better to have a general way to modify headers then adding auth specific logic.

[lstrojny]

Do I understand it correctly that you want to do something like this?

$client = ...
$transport = $client->getTransport();
if (!$transport instanceof HttpTransportInterface) {
    // error handling
}
// Set auth headers
$transport->setHeader('Auth', 'foo');

[sagikazarmark]

Exactly

[sagikazarmark]

However as I stated above opening API might not be the best idea. I am open to suggestions, but (as I also stated above) generally being able to send custom headers using HttpTransport is a good idea.

[sagikazarmark]

@lstrojny thoughts?

[lstrojny]

The more I think about it, the more I feel this is really something to be configured on construction of the transport. For very simple use cases, addHeader(s) might be enough (as exposed in the HttpTransportInterface) but it should be done on construction as changing the state of the transport in between opens a can of worms. An alternative could be to think of a bunch of common authentication paradigms and unify them in the HttpTransportInterface. Obvious mechanisms seem to be HTTP auth and HTTP digest.

[sagikazarmark]

From my point of view a Client is (usually) used with some sort of injection (injecting into interfaces interacting with an XML RPC server, etc). That said it is essential that the object using the Client can somehow modify the request sent to the server. Authentication is the most common example I can think of. However I also think that the transport layer is not something that should be touched runtime. So I am struggling ATM, since the interface I am using sets the authentication itslef, while this really awesome library which made it possible to remove http client adapters does not make it possible.

[lstrojny]

Hmmm, in my apps I usually give concrete clients a name. So there might be $drupal XML/RPC client that is correctly configured for my CMS or a $magento SOAP client which is configured for Magento. Authentication should not really be the concern of the client using the ClientInterface, it should "just work".

[sagikazarmark]

Let's say I accept this reasoning. This means that the client using ClientInterface has no access to the request parameters itslef (apart from XML-RPC namespace, method and arguments). That is OK in case this client is nothing more than a decorator for your ClientInterface, or uses it directly. If the ClientInterface is injected in some sort of adapter implementation (eg. a data source of something), then this adapter can possible be exchanged with another adapter, meaning the authentication must be out of the adapter's scope. By moving it to the adapter level you can control it from any point of the application since you have an interface for it.

My current usecase is a supervisord php implementation where there is an adapter with your library and there is an adapter which sends HTTP requests to a unix socket. In this case it is obviously better to care about the authentication in the adapter and not the clients, since the authentication itself is not request dependent. However this last statement may be arguable.

[lstrojny]

Understood, interesting use case. Here is what you could probably do from an instanciation perspective:

httpClient = new HttpClient
bridge = new HttpClientBridge(httpClient)
specificA = new XmlRpcClient(bridge)
specificB = new XmlRpcClient(bridge)

Therefore specificA and specificB can reuse your httpClient (and therefore the authentication) but specificA and specificB still don’t need to know about authentication (and neither its clients).

[sagikazarmark]

Hm...

So an adapter becomes a ClientInterface? Or specificA and specificB are instance of the same ClientInterface and can be injected into the adapter?

[sagikazarmark]

I will probably do the following:
Typehint the adapter for ClientInterface.
Create an own interface, and check whether the passed client is an instance of my interface. If yes, I can set the authentication details, otherwise deal with the HTTP response.

I can't find anything better. However, I still do think that (not necessarily by modifying the http transport itself) the client should be able to modify the request. (But I could be wrong)

[lstrojny]

Alright, hope fxmlrpc will serve you well otherwise. Closing for now!

[sagikazarmark]

Thanks

[OnkelTem]

@lstrojny Would you provide an example of HTTP authorization? It's not clear at all. With all these dozens of adapters and things...

[OnkelTem]

Let me be more descriptive.

This doesn't work:

use Http\Adapter\Guzzle6\Client;
use Http\Message\MessageFactory\DiactorosMessageFactory;

$httpClient = new GuzzleHttp\Client([
  'defaults' => [
    'auth' => ['username', 'password']
  ],
]);

$client = new fXmlRpc\Client(
  'http://endpoint',
  new fXmlRpc\Transport\HttpAdapterTransport(
    new DiactorosMessageFactory(),
    new Client($httpClient)
  )
);

$result = $client->call(...);

i.e. it doesn't log in.

[OnkelTem]

Ok, nevermind, I should have passed auth option to Guzzle Client directly:

$httpClient = new GuzzleHttp\Client([
  'auth' => ['username', 'password']
]);

[sagikazarmark]

Yep, the last one is the latest structure. It depends on your Guzzle version.

[EdgarSedov]

Library client fXmlRpc/Client does not provide public methods to add custom headers for request, which makes it impossible to use it when u have to provide custom headers or their values which differs for each request