-1

How is it possible that perfectly straightforward, conventional, PHP web code that worked perfectly while hosted on Network Solutions​ does not work on GoDaddy​ while both service providers are ostensibly running the same versions of PHP and Linux Apache. The code WORKED on NetSol but not on GoDaddy: Why on one and not on the other ~ that is the question?

None of the previous answers I've found here in Stackoverflow address this particular issue and, in addition, having nonetheless tried those answers just in case, I can attest that they do not resolve this issue.

The issue is simple: 2 well established, built-in, PHP functions will not work on GoDaddy - but do on NetSol: After extensively Googling, and also reviewing Stackoverflow, for an answer - none of which links actually provide an answer to this question - and even after talking to a GoDaddy support tech, I finally admit defeat: I do not understand or know why these functions do not/will not work on GoDaddy but do work perfectly, and as expected/as designed, on Network Solutions.

On Network Solutions, calling if(session_regenerate_id(true)) always produces a boolean true result when appropriate. The exact same code on GoDaddy NEVER produces a true result. Not only that, on NetSol, the session_id does get updated/changed as desired and as expected but not so on GoDaddy.

Likewise, On Network Solutions, calling if(setcookie($name, $value, $expire, $path, $domain, $secure, $httponly)) always produces a boolean true result when appropriate. The exact same code on GoDaddy NEVER produces a true result. Not only that, on NetSol, the related cookie does get created/updated/deleted as desired and as expected but not so on GoDaddy.

I would dearly love to find out why something that works in one service provider environment does not in the other or else I am taking up flower arranging as a career; even mucking out horse stables or cow sheds ~ something I have not done recently :) would be preferable to spending any more time trying to figure this out I am frustrated enough to consider that as an option!!!

Please do not refer me back to links like session_regenerate_id(true) not work or PHP Regenerating session ID on login / out not working. I've tried those suggestions and they do not resolve this issue.

Community
  • 1
  • 1
Peter Beddows
  • 1
  • 3
  • 1
    None of these functions are hoster-specific. Nobody cares about your hoster. That's irrelevant to the question. The PHP configuration, error.log and error_reporting are what would be important. – mario Jul 11 '15 at 19:28
  • Thank you @mario. I know the hosting service should be irrelevant but, as of this moment, the different hosting service providers are the only apparent difference - ergo: why do we get different results? I have scoured the phpinfo.php results for both and I have scoured the related PHP configuration files but have not noticed anything that would explain the different results. – Peter Beddows Jul 11 '15 at 19:32
  • 2
    Well, *you* must provide `phpinfo()` excerpts. Nobody here will spy out the relevant information from either. And again: `error_reporting` and `error.log`. – mario Jul 11 '15 at 19:35
  • 1
    The first thing I'd check is the error log - find it, create an intentional error in a PHP file, run it, check the log to see if the error shows up in there, then look for any errors related to your code. The second thing to check is the actual code files - if you used FTP to transfer your files, make sure you transferred them as binary and not text – text mode inserts bogus newlines when it's bored, which play havoc with sessions. – DCoder Jul 11 '15 at 19:38
  • @mario You are understandably well respected in this community for your expertise and I thank you sincerely for taking time to help me with this. Nothing shows up in the error_log file. For testing purposes, I have isolated the "if(session_regenerate_id(true)){ }" function into its own sub function in which i run it as posted here with either a true }else{ false result respectively posting a responding simple text tracking msg to an error file in our MySQL db. No posting of HTML involved either before or after calling the function. I get a false result on GoDaddy but not on NetSol – Peter Beddows Jul 11 '15 at 20:01
  • 1
    I've been trying to nudge you into enabling error_reporting+display_errors (which they're oftentimes not). Because I have a *feeling* this will just turn out to be the *most common* hiccup: [headers already sent by php](http://stackoverflow.com/questions/8028957/how-to-fix-headers-already-sent-error-in-php) still. Otherwise debug your main sites´ setcookie() call per DevTools/Firebug network inspection, or commandline tools (`wget -S` or `curl -I`) to see if it actually sent anything. Else go for Martins´ debug list. – mario Jul 11 '15 at 20:06
  • @DCoder Thank you for responding. 1st: As posted to reply from mario, no error shows in error_log. 2nd: Understood about binary v ascii file transfers. I use File Zilla. I am also using a Win 7 Pro 64 Bit on Gigabyte mb with 8 core AMD cpu locally and Adobe Dreamweaver CC2015. So the code posted to Network Solutions and to GoDaddy originate from the same windows' folder source via the same mechanism. "if(setcookie(){}" has also been setup in isolation in its own sub function, No HTML involved, just a true }else{ false simple text tracking msg result posting to an error file in our MySQL db. – Peter Beddows Jul 11 '15 at 20:13
  • @mario: Got it! I'll give that error_reporting suggestion a try and report back. Thank you; very much appreciated. – Peter Beddows Jul 11 '15 at 20:15
  • @mario, I guess it will come as no surprise to you to now know that you were right: Somehow, have not figured out just where yet but wanted to give you feedback AQAP, there is now a rogue loop back buried somewhere in my code that does lead to the start of the next page http activity before the new session_id and setcookie process has been completed. c'est la vie! – Peter Beddows Jul 12 '15 at 00:03

1 Answers1

0

Have you used PHP.ini or other direct INI edits in page to specify an accessible location to store the session data on the server? For example 

session.savepath=/home/mysite/tmp/session

in PHP.ini. Try this on both servers to set a clearly defined and clearly accessed folder for session data, with mod 0755 on the folder, just to be sure. I think I'm running on the basis that the session is not working in general, but to clarify (sorry): the session behaviour does work but the session regeneration only does not work?

  • Are both servers running the same version of PHP?
  • Have you tried manually setting a name for the session for your website with session_name() ?
  • Are both servers filesystems / accesses structured in a similar way?
  • Have you found any error log errors relating to $_SESSION on either server?
  • Have you tried to view phpinfo() on each server to view differences in settings?

And finally a silly question but:

  • What did the GoDaddy Support actually say?

I hope with the answers I can update this anwser to give a better - more, er, answering, answer. :)

edit:

Can you confirm you have checked that:

When session.use_trans_sid is enabled, output must be started after session_regenerate_id() call. Otherwise, old session ID is used.

  • Also, what are the actual values you use in your setcookie call? The setting of the cookie on different servers will probably involve different values on this.
Martin
  • 22,212
  • 11
  • 70
  • 132
  • thank you very much for your contribution. turns out that I have somehow actually have compromised my own code. Previously, nothing was showing in the error_log. However, after following Mario's, I realised that I was not getting the whole error picture. With error tracking now set to - error_reporting(E_ALL | E_STRICT) - shows that there now is a loop back that leads to early http code being sent before session regen process has completed. So now I just have to find where this erroneous looping is occurring. Thank you for your input; I will also look into your suggestion. – Peter Beddows Jul 12 '15 at 00:19
  • Well thanks for letting us know, @PeterBeddows and glad you have a lead to follow in solving your problem. When you have found a solution, it would be really good if you can edit your question, or post your own answer to this question to explain to future people reading this topic what you did to fix your issue, cheers. :-) – Martin Jul 12 '15 at 08:12