1 (edited by cweiske 2017-05-05 10:42:11)

Topic: .phar support in web server configuration

It would be nice if the web server (apache or nginx) would not only handle .php files, but also execute .phar files.

PHP applications can be packaged up into a single .phar file, which makes deployment and testing very simple.

Details: http://cweiske.de/tagebuch/phar-webserver.htm

I once opened a bug report for fedora but that was closed because of EOL of the package I reported it for, see bugzilla.redhat.com/show_bug.cgi?id=1117140 (forum error: too many links)

This will land in Debian as well, see gitlab.sury.org/pkg-php/php/commit/e40036fba414accca4c95d55f76eeedb38600393

Re: .phar support in web server configuration

I remember of this RFE.

BTW, I was a bit uncertain about fixing it because of security effect of possible existing .phar archive stored in buildroot, and not expected to be executed. IIRC, I've asked security team about this, but don't remember having any answer.

More, we are used to not changed default provided configuration for "stable" release, so If managed, will only happen in 7.2 (fedora 27)

Have to think a bit more about this.

I know .phar are very common for CLI command distribution (composer, phpunit, phpcs...) but have never see any webapp distributed in this way.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: .phar support in web server configuration

About the link to your documentation, AddHandler is deprecated (for security reason) wink   and thus fedora only use FileMatch + SetHandler.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: .phar support in web server configuration

Remi wrote:

If managed, will only happen in 7.2 (fedora 27)

This would be fully fine for me.


Remi wrote:

I know .phar are very common for CLI command distribution (composer, phpunit, phpcs...) but have never see any webapp distributed in this way.

This is a chicken-egg-problem. If .phar'red webapps cannot be used because web servers do not handle them, projects will not offer .phars.

I distribute several applications as .phar:

  • phorkie - cweiske.de/phorkie.htm

  • phancap - cweiske.de/phancap.htm

  • bdrem - cweiske.de/bdrem.htm

Re: .phar support in web server configuration

Example of side effects which have to be handle if applied

in wordpress configuration (package)

<Directory /usr/share/wordpress/wp-content/uploads>
  # Deny access to any php file in the uploads directory
  <FilesMatch "\.(php)$">
    Order Deny,Allow
    Deny from all
  </FilesMatch>
</Directory>

So this have to be extended to also forbid .phar (even if already forbidden in the webUI)

Probably, some other app, everything need to be checked.

P.S. well, in fact, in "correctly" packaged web app, data should not be readable via http... but wordpress...

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: .phar support in web server configuration

Quick notes, trying to have this working with nginx (as, in Fedora, we provide a default configuration for NGINX/PHP-FPM working "out-of-the-box")

So nice web-app (aka, well-packaged) should work after installation, without editing any configuration, with
- apache + mod_php
- apache + php-fpm
- nginx + php-fpm

From your documentation

    fastcgi_split_path_info ^(.+\.(?:php|phar))(/.+)$;

Calling /phorkie.phar result in "phorkie can only be used in the browser"

(because redirected to /phorkie.phar/index.php, because of "fastcgi_index" directive)
(perhaps something you can handle in phorkie)

Seems better with

    fastcgi_split_path_info ^(.+\.(?:php|phar))(/.*)$;

Another problem, calling /phorkie.phar/setup strangely resuts in a 500 error...
(when cache and repos directories exists, everything works...)

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: .phar support in web server configuration

Remi wrote:

Seems better with

    fastcgi_split_path_info ^(.+\.(?:php|phar))(/.*)$;

Yes, that is better. Please keep it that way.

Remi wrote:

Another problem, calling /phorkie.phar/setup strangely resuts in a 500 error...
(when cache and repos directories exists, everything works...)

The setup script returns a 500, but actually shows the errors. nginx replaces the phorkie-generated error page with its own. I did not anticipate that.

See http://fotos.cweiske.de/screenshots/201 … 20fail.png

Re: .phar support in web server configuration

> The setup script returns a 500, but actually shows the errors.

Indeed, I noticed that with Apache.

> nginx replaces the phorkie-generated error page with its own.

Indeed, perhaps because of "fastcgi_intercept_errors"

> I did not anticipate that.

wink

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: .phar support in web server configuration

I think it's fine when the HTTP status code of the setup page is non-200 in case of errors. But if that breaks on Fedora's nginx, it's not so nice hmm No idea what's correct here.