getallheaders

[alexvasseur]

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

PCF 1.9 & PCF 1.7

What version of the buildpack you are using?

PHP bp 4.3.18

If you were attempting to accomplish a task, what was it you were attempting to do?

use of PHP native function getallheaders()

What did you expect to happen?

http://php.net/manual/en/function.getallheaders.php

What was the actual behavior?

2017-01-25T14:48:37.000+00:00 [APP] OUT 14:48:37 httpd | [Wed Jan 25 14:48:37.878268 2017] [proxy_fcgi:error] [pid 49:tid 140605208389376] [client 172.16.1.1:35546] AH01071: Got error 'PHP message: PHP Fatal error: Call to undefined function getallheaders() in /home/vcap/app/htdocs/index.php on line 3\n', referer: https://XXX

/organizations/d4dbf194-09dd-4980-b9cb-1809eca4ec6c/spaces/92860b17-4bc6-4f3c-9005-f887693d3f6f/applications/623bf335-12bd-48a6-a27d-ca46f6845a4e

code is

<?php

echo getallheaders();


phpinfo();

echo "<hr/>";

echo getallheaders();

echo "<hr/>";

?>

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/138331759

The labels on this github issue will be updated when the story is started.

[dmikusa]

From the docs...

This function is an alias for apache_request_headers(). Please read the apache_request_headers() documentation for more information on how this function works.

The apache_* methods are only available when you are running using mod_php. The PHP build pack does not install or use mod_php. It uses nginx or HTTPD talking to PHP via fastcgi. You'll need to use some other method to get access to the headers.

[alexvasseur]

That was unclear if the buildpack could be configured with mod_php - as I see there are different things (cfi, fm, pear, etc).
Could you confirm the only way is to manually impl the getheaders (which is easy) - and that the buildpack cannot be configured with mod_php.

[dmikusa]

It would be challenging to use mod_php. The binaries that we produce don't build mod_php, so that would be the first step to making this work. From there, you need to reconfigure HTTPD to use the module and not php-fpm, and you'd need to change the start command which will start the php-fpm processes. All in all, it would require a lot of changes to the build pack, possibly even a fork. Not something I would recommend unless it's absolutely necessary to get your app running.

[ajitrishabh]

what is the solution to get the header data ??

[dmikusa]

$_SERVER or $_ENV would be an option. Headers are included there. They start with HTTP_.

Ex: $_SERVER['HTTP_X_FORWARDED_PROTO'] == https

[ajitrishabh]

@dmikusa-pivotal i need to get Authorization from the response .
in nodejs by doing this req.get('Authorization') i am getting Authorization code.
how i can do the same in PHP with same setup on SIEMENS Mindsphere paltform.

[dmikusa]

You should be able to get any header via $_SERVER['HTTP_<header>'].

https://stackoverflow.com/questions/541430/how-do-i-read-any-request-header-in-php#541450

[ajitrishabh]

i tried but not getting the token

nodejs response if you can guide by seeing this
"host": "tokenkeyapp-ipmindev.apps.eu1.mindsphere.io", "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36", "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8", "accept-encoding": "gzip", "accept-language": "en-US,en;q=0.9", "authorization": "Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS1p

i want "authorization": "Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS1p`

[dmikusa]

Sorry, I knew this sounded familiar but had to refresh my memory a bit. Most headers you can get using the method above. Authorization is special because it can contain user id & password. By default, it's not passed along to scripts.

You should be able to allow it by adding this setting: https://httpd.apache.org/docs/2.4/en/mod/core.html#cgipassauth

If you add a .htaccess file to your app & put CGIPassAuth On in that file, I think that should make the Authorization header pass through. Alternatively, you can configure this way -> https://docs.cloudfoundry.org/buildpacks/php/gsg-php-config.html#engine-configurations

Other options are to have HTTPD handle this for you. Currently, Basic & digest auth can be done by dropping settings into a .htaccess file. When this PR is merged, you'll be able to make HTTPD perform Oauth2/OpenID authentication too.

cloudfoundry/binary-builder#41

[dmikusa]

I believe that we provide this module as well. In theory, it would allow you to create a FastCGI authorizer which can make authorization decisions. I haven't done this though, so it might take more work and customizations to make it actually work. If you go this route and do get it working, feel free to share what you find. Perhaps we could do something to make support of this scenario easier.

https://httpd.apache.org/docs/2.4/mod/mod_authnz_fcgi.html

[dmikusa]

@sclevine - We might want to consider doing this out-of-the-box.

#190 (comment)

The main reason I've heard it is disabled by default is to prevent accidental disclosure of a username/password to the script that's running, but in our use case the HTTPD server is specifically set up to service the scripts, thus it's a fair assumption that the scripts are trusted.

I don't think it would have any other implications.

[ajitrishabh]

@dmikusa-pivotal You are the Man. Thanks you so much.
by using your first suggestion related to **CGIPassAuth ** now i am able to get the token.

now i am facing one more issue is that when i am trying to use CF Sync Plugin i am getting the Application "cfphpapp" is not running on Diego
how i can run my application on Diego?
i raise the issue here but no solution yet.
cloudfoundry-attic/Diego-Enabler#12

any help is appreciated

[dmikusa]

All apps deployed to Cloud Foundry for probably the last three years have been on Diego. You'd be on a dangerously old version of CF if you're still using DEAs. I'm not sure where you are pushing your app, but if it's a public provider you're definitely on Diego. If your target is an on-premise CF deployment, you might want to check with your operator to see if they're still using DEAs.

Aside from that, check with the cf sync plugin author cause it's possible there is a bug in that plugin.