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.

Sign up for GitHub

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

Jump to bottom

Breaking included AWS Phar #21

Closed
neoacevedo opened this issue Mar 16, 2019 · 8 comments · Fixed by #31
Closed

Breaking included AWS Phar #21

neoacevedo opened this issue Mar 16, 2019 · 8 comments · Fixed by #31
Labels
bug Something isn't working

Comments

@neoacevedo
Copy link

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
Copy link
Member

ohader 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
Copy link
Author

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
Copy link
Member

ohader commented Mar 17, 2019 •
edited
Loading

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 Something isn't working label Mar 17, 2019
@ohader
Copy link
Member

ohader 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
@ohader
[BUGFIX] Consider direct alias invocation without being registered
6d1f113 
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
@ohader ohader mentioned this issue Mar 17, 2019
Closed
@diehlaws diehlaws mentioned this issue Mar 19, 2019
Closed
@neoacevedo
Copy link
Author

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

@jurihahn
Copy link

jurihahn commented Apr 9, 2019

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

@jurihahn jurihahn mentioned this issue Apr 10, 2019
Closed
@jurihahn
Copy link

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
@ohader
[BUGFIX] Enhance alias resolving and reduce file system invocation
b9d2f0b 
* 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 ohader mentioned this issue Apr 27, 2019
Merged
ohader added a commit that referenced this issue Apr 28, 2019
@ohader
[BUGFIX] Enhance alias resolving and reduce file system invocation
a1349b3 
* 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 ohader mentioned this issue Apr 28, 2019
Merged
@ohader
Copy link
Member

ohader 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 as completed in #31 May 5, 2019
ohader added a commit that referenced this issue May 5, 2019
@ohader
[BUGFIX] Enhance alias resolving and reduce file system invocation
eb6607f 
* 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
@ohader
[BUGFIX] Enhance alias resolving and reduce file system invocation
09609ce 
* 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
@johanjanssens johanjanssens mentioned this issue Jun 30, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[BUGFIX] Enhance alias resolving and reduce file system invocation [v3] TYPO3/phar-stream-wrapper
3 participants
@ohader @neoacevedo @jurihahn