Nice to have the version of eZ in the X-Powered-By http header

[jdespatis]

Which is already the case in:

• kernel/setup/datatype.php
• kernel/setup/templateoperator.php

(the same logic has been spread whenever an X-Powered-By is used)

Nice to have this version number in order (later) for eZ Systems to scan all websites using eZ, in order to know the usage per version of eZ

Further more, existing scanning tools will know what version of eZ is involved

[bdunogier]

Comment valid for all cluster handlers: the main issue is that the index_image_ files do NOT load the autoload, in order to maximize performances. The only proper way would be to replicate the current version in here.

While working for a new cluster handler, I have considered adding this as an option to the index_cluster.php file (the one where parameters are). This would also make it possible to cleanly disable this header, by assigning false to this parameter.

[jdespatis]

Ok, so no chance for this patch to work :)
Where is the index_cluster.php file ? in order to correct the patch

[bdunogier]

Honestly, Jérôme, I'd rather not include any file from this sequence.

This is what I have on my local branch:

// index_cluster.php (manually created, contains DB parameters + optional parameters)
define( 'HEADER_X_POWERED_BY', 'My X-POWERED-BY header' );

Actual cluster index file:

// index_image_xxx.php
if ( !defined( 'HEADER_X_POWERED_BY' ) )
  define( 'HEADER_X_POWERED_BY', 'eZ Publish' );
[...]
if ( HEADER_X_POWERED_BY !== false )
  header( "X-Powered-By: " . HEADER_X_POWERED_BY );

With this method, you can easily customize/disable it. What do you think ?

[jdespatis]

I've seen index_image.php that seems to be the controller loaded first, maybe some files are loaded also with index_image.php ?
maybe any config file where the version of eZ could be put ?

[jdespatis]

Another question for you @bdunogier fmi:
why are you setting a custom x-powered-by header on your local branch indeed?

[jdespatis]

eZ already exposes its version in 2 files (kernel/setup/datatype.php & kernel/setup/templateoperator.php), I've just spread this logic everywhere

I agree with you though, would be a nice feature, maybe a function somewhere that returns the x-powered-by string to use

(From my point of view, as eZ should always run behind a varnish to have a decent speed, this header can then be easily tuned thanks to the marvelous varnish)

[dpobel]

I disagree on this because of "security" reason. Usually, it's better to not expose the version number of a software to avoid the easy discovery of security flaws affecting a site.

[jdespatis]

It may also be nice to expose it, in order for eZ Systems (and even lots of existing scanning tools) to create statistics on usage per version, as it's already the case for client browser, or webserver like apache (that exposes its version by default)

So maybe best way would be to have a function used to show the signature of eZ, that can be tuned by a setting (in fact exactly the same way as Apache does with ServerSignature setting)

(Basically I agree with you Damien, I even prefer to hide completely the x-powered-by..., varnish does this easily)

But you know, even by hiding the version, a hacker will scan and test security issues, whatever the x-powered-by says...
http://www.whitefirdesign.com/blog/2011/03/02/hiding-the-wordpress-version-number-will-not-make-your-website-more-secure/

[gggeek]

I vote for making this header completely optional - so that users that are either security freaks or response-size freaks do not have to set up stripping rules in their reverse proxies

[andrerom]

Actually we almost removed the whole X-Powered-By header cause some clients did not want it to be there.
So -1 from me on adding version in there I think.

[jdespatis]

Oh some clients refusing this header ? (I thought all headers starting with 'x-' were accepted)
For my interest, which kind of clients are you talking about André?

So maybe best solution would be to drop this header everywhere (and not even being able to tune the content as discussed before, to include the version or not, for security reasons)

[andrerom]

I don't remember the details, it was prioritized by Roland the PM at the time(last year), but there where some complications / dependencies that made the cost of removing it to high for him so it was eventually prioritized down (I think this was just before 4.4 came out).

[jdespatis]

André, do you think it's possible to have a link/resource from Roland explaining the remove of this header?

I would really like to know more, as I often see this custom header in several codes around

[gggeek]

@jdespatis - I think AR meant some clients as in "customers", not as in "http clients". Now, customers might of course refuse a header because they have code that chokes on it, but they also might have other reasons...

[andrerom]

I think AR meant some clients as in "customers"

Correct

[jdespatis]

As quoted by @bdunogier, there seems to be an important point: it doesn't seem to be possible to have a static function used in the index_*.php, as autoload is not loaded there (and by default config.php is disabled)

So no way to have a generic customized (by an ini file) x-powered-by in those files.

As a result, for genericity, I think it's even better to not show a dynamic value (the eZ version) in this http header... And just let "eZ Publish" static string

=> so why not closing this pull and creating a new one that just vanishes the version from: ?

• kernel/setup/datatype.php
• kernel/setup/templateoperator.php

And in an near future, maybe create another issue that vanishes completely the x-powered-by, as quoted by @andrerom.
However on this point, when a customer is paying for eZ Entreprise, he has the money to use the varnish extension (and then can clean easily this header)

So if I were you, I would consider to let the eZ signature (nice to perform some 'advertisement' when a user uses the eZ comunity version...)

Just my 2 cts

[bdunogier]

@jdespatis: I'll end up merging the code I've shown you, in any case. I know it would be cleaner if lib/version.php was included, but to be honest, I'd rather not. It's not that big a deal if you just have to customize this.

With this change, you'll have:

• a default header of "eZ Publish"
• the option to use the actual value, build #, etc, by setting the constant (custom file, no hack required)
• the option to completely disable this header by setting the constant to false.

Acceptable, right ?

[jdespatis]

So it's a new try

As discussed above, it's better to not expose the version of eZPublish. But it seems to be impossible to have just one single setting to change to propagate the inclusion of the version or not (due to the index_*.php that doesn't include the ini stuff)

=> As a result, it's better to hide the version everywhere, and have the same logic everywhere

What do you think about this one ?

@bdunogier: I can add a change in the pull with your define() process, but it would be a logic only specific to the index_*.php, so not a generic method. Further more, as quoted by André, it seems that the X-Powered-By may disappear in the long run (would be really pity indeed)

[bdunogier]

I agree with the pull request now.

Anybody else ?

[andrerom]

+1 ( as in only merge commit fd04b0e to keep history clean)