Comments (25)
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.
from fxmlrpc.
The point is (as I said earlier) I don't now about the transport, only the injected Client.
from fxmlrpc.
Ah right, then I guess you'd have to make a pull request to implement a getter for the transport property.
from fxmlrpc.
Probably yes. However I am not sure if opening the API is a good idea.
from fxmlrpc.
That would also mean that I should put it in the interface as well. Which should be thought wisely.
from fxmlrpc.
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.
from fxmlrpc.
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.
from fxmlrpc.
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');
from fxmlrpc.
Exactly
from fxmlrpc.
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.
from fxmlrpc.
@lstrojny thoughts?
from fxmlrpc.
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.
from fxmlrpc.
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.
from fxmlrpc.
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".
from fxmlrpc.
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.
from fxmlrpc.
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).
from fxmlrpc.
Hm...
So an adapter becomes a ClientInterface
? Or specificA
and specificB
are instance of the same ClientInterface
and can be injected into the adapter?
from fxmlrpc.
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)
from fxmlrpc.
Alright, hope fxmlrpc will serve you well otherwise. Closing for now!
from fxmlrpc.
Thanks
from fxmlrpc.
@lstrojny Would you provide an example of HTTP authorization? It's not clear at all. With all these dozens of adapters and things...
from fxmlrpc.
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.
from fxmlrpc.
Ok, nevermind, I should have passed auth
option to Guzzle Client directly:
$httpClient = new GuzzleHttp\Client([
'auth' => ['username', 'password']
]);
from fxmlrpc.
Yep, the last one is the latest structure. It depends on your Guzzle version.
from fxmlrpc.
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
from fxmlrpc.
Related Issues (20)
- Confusing $isFault in Client HOT 2
- Can't parse XML the $xmlParser->parse($xmlString) return null on valid XML HOT 1
- Ivory is deprecated in favor of php-http HOT 5
- Uncaught RuntimeException: Puli Factory is not available HOT 1
- Make zendframework/zend-diactoros, php-http/message and php-http/guzzle6-adapter dependencies HOT 2
- Use php-cs-fixer HOT 1
- Finalize exported serialization package HOT 7
- Installation HOT 2
- 6MB XML file HOT 2
- Cannot install guzzle6 adapter HOT 1
- Package not updated @packagist HOT 1
- Slow speed tests HOT 1
- zend-diactoros is abandoned HOT 3
- Implement PSR-17/18 adapter for direct connection to Guzzle 7
- PHP 8 support HOT 9
- array with one integer key not zero converted to array and not to struct HOT 4
- [Bug] Implementation of PSR 17 Factories breaks requests
- New tag HOT 2
- NativeParser Issue
- Phpunit integration tests failing on require-dev guzzle7-adapter due to mishandling of 500 errors.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fxmlrpc.