On installation you may (or not) notice that you can not write into $_SERVER e.g. this little program does not allow changes in your $_SERVER
<?php
print_r($_SERVER);
echo '<br><br>';
$_SERVER['MYTEST']='FAIL OR SUCCEED';
print_r($_SERVER);
?>
The solution is to edit the httpd.conf in your c:\Program Files (x86)\NetMake\v8\components\apache\conf\ directory and uncomment the line to:
LoadModule headers_module modules/mod_headers.so
Underscoring seems to be an interesting issue too…
thanks rr 
obviously interesting indeed.
Just curious, why you want/need to write on $_SERVER superglobal? it’s an information var.
I know but one of my colleagues needs to use PEAR LDAP which needs to set and change a $_SERVER variable. Apparently that package needs it. I personally would avoid it completely, I dont like people being allowed to fiddle on the $_SERVER variable. Luckily it is not possible to fiddle on the really important $_SERVER variables so no security issues there…
Well, that collegue himself does not want to set or change a $_SERVER-variable… Just read it after it is set by a Single Sign On server managed by again another collegue…
Many collegues overhere.
Send me a SIMPLE (simplest as possible) program that you think that works and I can test it… Please put it online to that I can test it in detail and find out WHY it doesnt work…
Sorry, i’ve completely lost you here. Please contact the other collegue I told you about. He can tell how the SSO-server works and how he wants to do this.
For people who want to fiddle with $_SERVER-vars themselves and find out what works and what doesn’t work in the Scriptcase development-environment or your webserver-environment: install a modify-header addon in your browser and then read the var set with the addon
http://mybrowseraddon.com/modify-header-value.html for Chrome
or
https://addons.mozilla.org/en-US/fir…odify-headers/ for Firefox
You don’t need a PHP-program.
As long as it is done in the same browser as the app uses it works. I think the SSO-server uses the same technique as the browser-addon does. The client-browser contacts the SSO-server and there is checked if the user is logged in. If not a login-dialog is presented by the SSO-server and after providing the right credentials the SSO-server sets the $_SERVER-var just as the above mentioned browser-addons do.
Other webapps then do not need to login again; just check if the $_SERVER-var exists. Security issue you say? Maybe, but I can’t imagine those SSO-collegues haven’t thought about that. So maybe in the end it is a bit more complicated. We’ll see.
Wow, too mych colleagues, but…who pays the beers?
Albert should do. loooooooool