imbo / imboclient-php

A client for Imbo written in PHP

Imbo

Imbo is an image "server" that can be used to add/get/delete images using a REST interface. There is also support for adding meta data to an image. The main idea behind Imbo is to have a place to store high quality original images and to use the REST interface to fetch variations of those images. Imbo will resize, rotate, crop (amongst other features) on the fly so you won't have to store all the different variations.

Installation / Configuration / Documentation

End-user docs can be found here.

License

Licensed under the MIT License.

imboclient-php's Issues

addRequestHeader in the driver adds the same headers

When using the addRequestHeader() method in the driver the same header might end up several times.

Include examples of proper error-handling

I think the documentation/readme should include an example which actually uses proper error handling (try/catching with the various exception types, etc).

Multiple key pairs in the client

The client should be able to hold several public/private key pairs, and not only one. Example on how it can be used:

<?php
$client = new ImboClient\Client('http://imbo', array(
    'user1' => 'privatekey1',
    'user2' => 'privatekey2'
));

All methods fetching URL's and adding images and such must get a new optional parameter, identifying which user we are performing the operation as:

<?php
$statusUrl = $client->getStatusUrl('user1');
$userUrl = $client->getUserUrl('user1');
$imagesUrl = $client->getImagesUrl('user1');
$imageUrl = $client->getImageUrl('imageidentifier', 'user1');
$metadataUrl = $client->getMetadataUrl('imageidentifier', 'user1');
$response = $client->addImage('/path/to/image.png', 'user1');

Would it be an idea to also handle the case where users use different sets of servers?

<?php
$client = new ImboClient\Client(array(
    'user1' => array(
        'privateKey' => 'secretKey',
        'hosts' => array(
            'http://imbo1',
        ),
    ),
    'user2' => array(
        'privateKey' => 'superSecretKey',
        'hosts' => array(
            'http://foobar1',
            'http://foobar'2,
        ),
    ),
));

Thoughts?

Allow passing cURL-driver options related to SSL

The related options in question;

CURLOPT_SSL_VERIFYPEER
CURLOPT_SSL_VERIFYHOST
CURLOPT_CAINFO
CURLOPT_CAPATH

Generating image URL's with no image identifier should not be possible

Today the client allows for image URL's with no image identifier:

<?php
echo $client->getImageUrl(''); // http://host/users/user/images/?publicKey=key&accessToken=token

This should not be possible, and the client should throw an exception (for instance InvalidArgumentException). The main issue is that the URL is valid, and will hit the images endpoint, causing a search for images on the server.

Method for adding images via URLs

The client should have a method for adding images to a remote imbo server based on an URL.

Implement new access control

With the upcoming access control changes, we'll have to modify the client a bit.

1. There needs to be a clear distinction between a user and a public key
2. There should possibly be a way to specify public and private keys on a per-command basis
3. Public key should be sent as header instead of assuming it's present in the URL

Obviously, documentation also needs to be updated to reflect the changes.

Does anyone have any suggestions on how the API would look best in regards to point 2?

signature mismatch

when using the same public and private key pairs on both client and server, i get the signature mismatch error. the server generates a different signature than the client.

may i suggest extracting the signature manipulation into a separate class or lib, which both the client and server would use?

can't upload facebook profile picture

(originally created by @bazo over at imbo/imbo#118, check that issue for more details)

hi,

i tried adding a facebook profile picture either in format https://graph.facebook.com/user.name/picture or https://graph.facebook.com/user.id/picture which both resolve to https://fbcdn-profile-a.akamaihd.net/hprofile-ak-ash3/some_id_id_id_q.jpg via the addImageFromUrl function.

all of them gave me the ImboClient\Exception\RuntimeException

An error occured. Could not complete request (Response code: 0)

then i tried this picture http://upload.wikimedia.org/wikipedia/commons/1/1d/T-90_Bhisma_cropped.jpg. it worked ok.

what can be the problem? thanks

getImageProperties() does not work with develop branch of the server

Because of the support for Accept headers implemented in the develop branch over at imbo/imbo the client can no longer fetch image properties using the getImageProperties() method. The reason is that the client specifies Accept: application/json in the constructor. This causes the server to respond with 406 Not Accepted when the client requests an image resource.

Consider upgrading PHP version requirement?

I think we should consider requiring PHP >= 5.5 for future versions of the client. If we make the next release of the client compatible with PHP 5.3 + Imbo 2.0, I think we can start working on a 2.0 of the client which requires a more recent PHP version.

Mainly I'm interested in using some more modern dependencies such as the latest Guzzle and Behat, but it would also be nice to be able to use short array syntax, for instance.

Add a method for adding images from in-memory data

The ImboClient\ClientInterface::addImage() method only takes a path to a file as an argument. The client should have a separate method for adding an image already read from a file.

Metadata query

Work has been started with the support of metadata queries in the server. The client must be able to support this as well.

getMetadata() returns the response and not the metadata

According to the docs (the client interface) the ImboClient\Client::getMetadata() method should return an array with metadata. The current implementation returns the complete response object. This should be changed to return the metadata only.

Update guzzle to newest version

Right now guzzle is pinned at 3.8, but there is a far newer version of guzzle avaiable.

transformations with the Client::getImageUrl

hi,

how do you use the transformations with this method?

i have uploaded an image, and now i would like to easily show it on the page, with lets say width x height = 160x160.

but how do i pass these parameters to the client?

i dont see any method which would allow me to do this. if i just add the parameters after the generated string i get invalid access token error.

could these transformations be specified when making the request for the url?

Old client incompatibilities

• ImboClient\ImboClient => ImboClient\Client
• The old ImboClient::factory method has been removed, use ImboClient\Client's constructor instead

Info in the response whether or not the image exists on the remote server

If the client does a PUT and the image already exists the ImboClient\Http\Response::isSuccess() method returns false, and the user would have to check the internal imbo error code for what really went wrong. The response should have a method called imageExists that informs the user whether or not the image in question exists.

Automatically add "http://" to the server URL(s) is not specified

When instantiating the client with a server URL that is missing "http://" the client should automatically add it.

imageExists() triggers exception if image does not exist

When using imageExists() against an image which does not exist on the server, the server responds with a 404 with no body. This causes several problems:

Firstly, the cURL driver fails to parse the body and triggers a PHP notice:
PHP Notice: Trying to get property of non-object in ImboClient/Driver/cURL.php on line 314

Secondly, it actually causes an exception to be thrown instead of simply returning false as expected.

Simple testcase:

<?php
$imbo = new ImboClient\Client($config['imbo']['host'], $config['imbo']['pubkey'], $config['imbo']['privkey']);
file_put_contents('some-new-file', 'blah');
var_dump($imbo->imageExists('some-new-file'));

Expected output: false.
Actual output: Uncaught exception + notices.

getImageProperties should return more information

The getImageProperties() method on the client should return more information regarding the image, for instance the extension and the mime type. Basically all image-related information present in the response headers.

Skip custom handling for old image identifiers when using multiple hosts

Imbo used to generate MD5 hashes as image identifiers. If the client is configured using multiple Imbo hosts it will deterministically choose a host based on the image identifier. Version 2 of the client includes custom logic to "correctly" choose the host when the image identifier looks like an MD5 hash. This custom logic should be removed in version 3.

Client has no method to fetch user information

The client should include a method that fetches user information.

ImboClient\Version reports "dev" when used from phar archive or composer

The ImboClient\Version class reports dev when the client is used from the phar archive, or from a composer "installation":

<?php
require '/path/to/imboclient.phar';

$v = new ImboClient\Version();
var_dump($v->getVersionNumber(), $v->getVersionString());

outputs:

string(3) "dev"
string(18) "ImboClient-php-dev"

This is because the component uses @package_version@ as a version string that is replaced by the PEAR installer when installed using PEAR.

Drivers should throw an exception if the response contains an error

Much easier to handle in the application, because now i have to check if the response->isSuccess and then extract the error from the json body response. not developer friendly and practical.

ImboClient does not remove an explicitly set port 443 from the URL when using https://

ImboClient removes :80 from the URL if it is added explicitly when creating an instance of the client. http://host:80 is changed internally to http://host. This does not happen when :443 is added to the URL when using https://. https://host:443 should be changed to https://host internally.

Provide a simple way to fetch the error from a failed request

It would be a nice addition to use internal error codes coupled with class constants for a reliable way to handle errors.

For example:

<?php
$response = $imbo->addImage($imgPath);
if (!$response->isSuccess()) {
    if ($response->getErrorCode() == self::IMAGE_ALREADY_EXISTS) {
        // Do something clever
    }
}

Update metadata responses

In the develop branch of the Imbo server the response to the metadata resource when using POST, PUT and DELETE has changed. This must be reflected in the client as well.

Add sharpen() and contrast()

Imbo-1.2.0 will have support for sharpen and contrast. This should be added to the ImageUrl class in the client as well.

The response can not be used in a string context of the body is empty

ImboClient\Http\Response\Response fails when used in a string context and the body is empty:

<?php
$response = new ImboClient\Http\Response\Response();
echo $response;

fails with:

PHP Catchable fatal error: Method ImboClient\Http\Response\Response::__toString() must return a string value

Implement cli-tool

The client should come with a cli tool that can be used to add/edit/delete images and metadata from command line.

incorrect access token

hi,

i've updated the imbo server to the last develop version and suddenly i get incorrect access token error even though my config file is unchanged

then i tried to switch the server to master branch, but then i get file not found error.

the file did exist before and displayed correctly.

any way out of this?

Allow specifying the user when calling ImboClient:getImageUrl

We're receiving image URLs from multiple sources and need to retain the user from the original URL.

We could solve this ourselves by using getUser/setUser to create a backup of the originally configured user, replace it with the user from the URL, generate the image, then restore the original user. This feels like a hack, though.

Would it be possible to add an (optional) second parameter to getImageUrl which would allow us to override the configured user on a case-by-case basis?

I'd be happy to provide a PR for this.