0

I've added a 2nd PHP environment (7.3.3) to IIS7.5 (required PHP update for compliance), and I have it assigned to a specific test directory - I can confirm with phpinfo() that this directory is now on v7.3.3.

The site that I setup on the new PHP version is now having issues with $_SESSION variables.

I have a blank PHP page that I'm using to troubleshoot. At the beginning of the document, I simply have session_start(). Then I'm trying to simply echo $_SESSION['sid'] - regardless of this variable being empty, it should still resolve the page, and echo nothing. However, this is returning an internal 500 server error.

I have a feeling that there is a setting in the new php.ini file for v7.3 that I'm missing for sessions. I've been doing some deep page googling with no luck yet, so now I'm here hoping for a nudge in the right direction.

Additionally, when I remark the session.save_path, and attempt to initialize the session_start() without the session variable, it also gives a 500 internal server error, so it appears that my session.save_path is setup correctly (had permissions already setup from prior PHP version build).

I've also tried displaying errors, but it just shows internal 500 server error still. If there's anything I should provide to help try and troubleshoot, please let me know.

β.εηοιτ.βε
  • 16,236
  • 11
  • 41
  • 53
TecHalo
  • 41
  • 7
  • What does the server error log show? That's where the 500 error information is logged. – Dave Apr 02 '19 at 19:29
  • If you set your debugging param correctly, nothing should prevent your from seeing the error message. Mind that an error 500 can come from virtually anywhere on the page, so do not focus on your sessions, for now. – β.εηοιτ.βε Apr 02 '19 at 19:29
  • If I understand correctly, your 7.3 is a test version, so feel free to set the right debugging settings in the php.ini of this version in order to troubleshoot further. Also see: https://stackoverflow.com/a/21429652/2123530 – β.εηοιτ.βε Apr 02 '19 at 19:31
  • Hello, and thank you all for the advice. I was able to successfully get the error log working and it returned the following: `2019-04-02 21:08:54 192.168.7.65 GET /portal/ - 443 - 192.168.50.245 Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/73.0.3683.86+Safari/537.36 500 0 0 265` I did some more digging, and found the issue with the authentication - I updated the Anonymous Authentication to use our domain credentials, and that fixed the problem! Thanks for the help in getting my mind working down a different track! – TecHalo Apr 02 '19 at 22:00

0 Answers0