Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking included AWS Phar #21

Closed
neoacevedo opened this issue Mar 16, 2019 · 8 comments

Comments

Projects
None yet
3 participants
@neoacevedo
Copy link

commented Mar 16, 2019

Hi. Joomla 3.9.4 updated/included this package.
Currently I'm using aws.phar to use for S3, but since last update, I'm getting this error:

Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar://aws-3.67.5.phar/aws-autoloader.php"

This error is related to this package, not in Joomla or my own code. Maybe a bug?

@ohader

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2019

Can you please point to the specific version of the aws.phar file, how it is used/included and mention the exact PHP version (and OS distribution) you're using? Thx

@neoacevedo

This comment has been minimized.

Copy link
Author

commented Mar 16, 2019

Hi.
It happens in any Linux version with PHP >= 7.1
I'm using the latest AWS phar file (3.90.3) and requiring it according with the AWS documentation: require '/path/to/aws.phar';

@ohader

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2019

Current workaround

instead of

require('/path/to/aws.phar');

please use (for the time being)

require('phar:///path/to/aws.phar/aws-autoloader.php');

This is what the stub of aws.phar is doing anyway internally.

Explanation

The stub of libraries like geoip2 (build with php-box) looks like the following. When invoking the phar:// stream, the full path is still given internally by using __FILE__. That way, the file path can be mapped to its internal alias name.

Phar::mapPhar('geoip2.phar');
require 'phar://' . __FILE__ . '/phar-stub.php';

The stub of the aws library looks like the following and does not contain any internal reference to it's original file. That's the reason why the internal alias aws-3.90.3.phar cannot be checked and results in an empty base-name. The work-around above uses the phar:// stream and thus triggers alias resolving.

Phar::mapPhar('aws-3.90.3.phar');
require 'phar://aws-3.90.3.phar/aws-autoloader.php';

@ohader ohader added the bug label Mar 17, 2019

@ohader

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2019

In PR #22 I've added test cases first in order to reproduce the behavior. Next step would be a fix...

ohader added a commit that referenced this issue Mar 17, 2019

[BUGFIX] Consider direct alias invocation without being registered
Invoking an aliased phar like `phar:///path/to/phar.phar/autoload.php`
would allow to extract and register a potential alias name of the base
name at `/path/to/phar.phar`. Using alias names directly inside phar
archive does provide any possibility to map its full path to an alias
(e.g. directly invoking `phar//alias.phar/autoload.php` would fail).

This change aims to resolve the original base name by walking the
current stack trace backwards. In terms of performance this is not
ideal, but it's the only chance to retrieve the required information.

Fixes: #21
@neoacevedo

This comment has been minimized.

Copy link
Author

commented Mar 19, 2019

I needed only require 'phar://aws-3.90.3.phar/aws-autoloader.php'; and it worked again.

@jurihahn

This comment has been minimized.

Copy link

commented Apr 9, 2019

@ohader this solution does not work with "geoip2.phar"?

@jurihahn

This comment has been minimized.

Copy link

commented Apr 11, 2019

i have workaround for "GeoIP2.phar"
require_once ( 'phar://' . __DIR__ . '/geoip2.phar/vendor/autoload.php' );

ohader added a commit that referenced this issue Apr 27, 2019

[BUGFIX] Enhance alias resolving and reduce file system invocation
* Consider direct alias invocation without being registered
  Invoking an aliased phar like `phar:///path/to/phar.phar/autoload.php`
  would allow to extract and register a potential alias name of the base
  name at `/path/to/phar.phar`. Using alias names directly inside phar
  archive does provide any possibility to map its full path to an alias
  (e.g. directly invoking `phar//alias.phar/autoload.php` would fail).
  This change aims to resolve the original base name by walking the
  current stack trace backwards. In terms of performance this is not
  ideal, but it's the only chance to retrieve the required information.
  That's also why the next section addresses performance.

* Enhance performance by reducing file system invocation
  Interceptors have to resolve the base file name from some given
  Phar invocation request. Internally the given path is traversed until
  a valid file is found in the file system and considered as the base
  name of the Phar archive.
  This change reduces superfluous calls to `is_file` when splitting
  the path in order to resolve the actual base name.

Resolves: #21
Resolves: #23

ohader added a commit that referenced this issue Apr 28, 2019

[BUGFIX] Enhance alias resolving and reduce file system invocation
* Consider direct alias invocation without being registered
  Invoking an aliased phar like `phar:///path/to/phar.phar/autoload.php`
  would allow to extract and register a potential alias name of the base
  name at `/path/to/phar.phar`. Using alias names directly inside phar
  archive does provide any possibility to map its full path to an alias
  (e.g. directly invoking `phar//alias.phar/autoload.php` would fail).
  This change aims to resolve the original base name by walking the
  current stack trace backwards. In terms of performance this is not
  ideal, but it's the only chance to retrieve the required information.
  That's also why the next section addresses performance.

* Enhance performance by reducing file system invocation
  Interceptors have to resolve the base file name from some given
  Phar invocation request. Internally the given path is traversed until
  a valid file is found in the file system and considered as the base
  name of the Phar archive.
  This change reduces superfluous calls to `is_file` when splitting
  the path in order to resolve the actual base name.

Resolves: #21
Resolves: #23
@ohader

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2019

Please test the references pull-requests #31 (PHP7) or #32 (PHP5) and check whether the originally reported bug of this ticket is solved. Thanks!

@ohader ohader closed this in #31 May 5, 2019

ohader added a commit that referenced this issue May 5, 2019

[BUGFIX] Enhance alias resolving and reduce file system invocation
* Consider direct alias invocation without being registered
  Invoking an aliased phar like `phar:///path/to/phar.phar/autoload.php`
  would allow to extract and register a potential alias name of the base
  name at `/path/to/phar.phar`. Using alias names directly inside phar
  archive does provide any possibility to map its full path to an alias
  (e.g. directly invoking `phar//alias.phar/autoload.php` would fail).
  This change aims to resolve the original base name by walking the
  current stack trace backwards. In terms of performance this is not
  ideal, but it's the only chance to retrieve the required information.
  That's also why the next section addresses performance.

* Enhance performance by reducing file system invocation
  Interceptors have to resolve the base file name from some given
  Phar invocation request. Internally the given path is traversed until
  a valid file is found in the file system and considered as the base
  name of the Phar archive.
  This change reduces superfluous calls to `is_file` when splitting
  the path in order to resolve the actual base name.

Resolves: #21
Resolves: #23

ohader added a commit that referenced this issue May 5, 2019

[BUGFIX] Enhance alias resolving and reduce file system invocation
* Consider direct alias invocation without being registered
  Invoking an aliased phar like `phar:///path/to/phar.phar/autoload.php`
  would allow to extract and register a potential alias name of the base
  name at `/path/to/phar.phar`. Using alias names directly inside phar
  archive does provide any possibility to map its full path to an alias
  (e.g. directly invoking `phar//alias.phar/autoload.php` would fail).
  This change aims to resolve the original base name by walking the
  current stack trace backwards. In terms of performance this is not
  ideal, but it's the only chance to retrieve the required information.
  That's also why the next section addresses performance.

* Enhance performance by reducing file system invocation
  Interceptors have to resolve the base file name from some given
  Phar invocation request. Internally the given path is traversed until
  a valid file is found in the file system and considered as the base
  name of the Phar archive.
  This change reduces superfluous calls to `is_file` when splitting
  the path in order to resolve the actual base name.

Resolves: #21
Resolves: #23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.