News:

Join the Facebook Fan Page.

Main Menu

SSI include causing wsod

Started by Sir Osis of Liver, February 17, 2021, 11:50:03 AM

Previous topic - Next topic

Sir Osis of Liver

Just patched this forum to 2.0.18, forum is fine but ssi.php include on website homepage is causing wsod.



<?
include_once('/home/mrennhack/public_html/forum/SSI.php');
$_SESSION['login_url'] = 'https://www.nukeworker.com/forum/';
if (!isset($context['session_var']))
$context['session_var'] = $_SESSION['session_var'];
$context['session_id'] = $_SESSION['session_value'];
?>



Page loads if include is commented out.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

vbgamer45

Try adding
ini_set("display_errors",1);
Before and after the include.


SSI seems to load on that site.
Community Suite for SMF - Take your forum to the next level built for SMF, Gallery,Store,Classifieds,Downloads,more!

SMFHacks.com -  Paid Modifications for SMF

Mods:
EzPortal - Portal System for SMF
SMF Gallery Pro
SMF Store SMF Classifieds Ad Seller Pro

Sir Osis of Liver

Wasn't working, then it was, now it's back to wsod.  There's a mod edit in SSI.php, will try removing it, see what happens.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Sir Osis of Liver

Tried this, nothing -



<?
ini_set("display_errors",1);
include_once('/home/mrennhack/public_html/forum/SSI.php');
$_SESSION['login_url'] = 'https://www.nukeworker.com/forum/';
if (!isset($context['session_var']))
$context['session_var'] = $_SESSION['session_var'];
$context['session_id'] = $_SESSION['session_value'];
ini_set("display_errors",1);
?>



Only difference in SSI.php is .18 core code contains this -



global $auth_secret, $cookie_no_auth_secret;



If I replace it with clean file, it loads once, but goes back to wsod.  Remove include, homepage loads.  Is there anything wrong with include code?
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Sir Osis of Liver

Uninstalled 2.0.18 patch, no good.  Uninstalled mod that was conflicting with patch in ManageSettings.php, no help.  Reinstalled .18 patch (no errors), I have it working now with SSI.php from 2.0.17 backup (attached).  Looks like it's all core except for bad behavior mod include.  Something in .18 patch is apparently causing the problem.

Version Information:
Forum version: SMF 2.0.18 (more detailed)
Current SMF version: SMF 2.0.18
GD version: bundled (2.1.0 compatible)
Database Server: MariaDB
MySQL version: 10.0.38-MariaDB
PHP: 7.1.33
Server version: Apache
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Kindred

just checked... SSI works fine on my systems. Running 2.0.18 with SSI functions being used on 3 sites.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

shawnb61

The good news is that there haven't been a lot of changes...

The file you provided has a mix of 2.0.18 & 2.0.17 code in it, & is missing some 2.0.17/2.0.18.  It looks like changes have been manually applied at some point.  It is actually closer to 2.0.18 than it is to .17. 

The file you provided is missing some auth_secret globals that are in both 2.0.17 & 2.0.18.

The only other real change is the magic_quotes_runtime check.  It won't go there if you are at 7.4 or greater.

Not quite sure what your issue is, but the first thing I'd do is see if adding the globals back reintroduces the issue.  If so, then there is an authentication problem of some sort.  I'd make sure your auth_secret settings make sense.

The bad behavior change looks very minor.  The next thing I'd try would be manually applying the BB change to a vanilla 2.0.18 file instead of this tweaked one.  If that works, you're done. 
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Sir Osis of Liver

It's inconsistent.  Worked for a while with .17 SSI.php backup, uploaded clean .18 file, broke it, reuploaded .17 backup, still broken.  Only thing that works consistently is removing include from website index.php.  Beginning to think it's a server caching issue, then I get this today -

Quote from: NukeWorker.com on February 18, 2021, 06:39:41 AM
It's still not working when people use an "incognito" mode, which forced it to use fresh resources.  OR some one they doesn't come to the site daily, and needs fresh resources.
For people like you and i that have files cashed, it works...

Server is logging a lot of these -

[Thu Feb 18 16:31:31.064071 2021] [core:crit] [pid 7481:tid 47674761463552] (13)Permission denied: [client 185.191.171.14:57604] AH00529: /home/mrennhack/public_html/404/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/mrennhack/public_html/404/' is executable
[Thu Feb 18 16:30:43.765814 2021] [core:crit] [pid 23791:tid 47674795083520] (13)Permission denied: [client 95.163.255.96:34068] AH00529: /home/mrennhack/public_html/404/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/mrennhack/public_html/404/' is executable
[Thu Feb 18 16:30:37.593116 2021] [core:crit] [pid 7481:tid 47674750957312] (13)Permission denied: [client 41.169.79.166:44186] AH00529: /home/mrennhack/public_html/404/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/mrennhack/public_html/404/' is executable
[Thu Feb 18 16:29:52.729338 2021] [core:crit] [pid 7481:tid 47674788779776] (13)Permission denied: [client 209.133.111.211:52392] AH00529: /home/mrennhack/public_html/404/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/mrennhack/public_html/404/' is executable


Removing .htaccess has no effect.

Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Sir Osis of Liver

If I rename SSI.php to ssi.php, and change filename to match in ssi include, it works. 

What does this mean? ???
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

shawnb61

That means you're on unix, which is case sensitive.

Odd that works, though.  I would search all code for all references to "ssi.php" and "SSI.php" and make sure they are consistent.  If your custom code has a lower-case version somewhere, that likely explains it.
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Sir Osis of Liver

I know it's case sensitive, that's why I changed it.  The include seems to be loading a bad SSI.php from somewhere else, possibly server cache.  When  file is renamed, include loads it correctly from forum and it works.  Rename it back to SSI.php, wsod.  I can rename all occurences of SSI.php in forum code (not that many), that may fix the problem but will probably bork future updates. 

The problem apparently started here, this was before I got involved.  Upgrade to 2.1 failed, host restored 2.0.17 backup.  I upped him to .18, down to .17, back to .18.  Same thing either way.  I have him checking with host re: server caching.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

shawnb61

Yes, I would leave them at SSI.php, but consistent.

The code uses an 'include'?  Normally we use a 'require' - I would be tempted to change it to 'require' & see if any behavior changes.  Maybe a require_once...
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Sir Osis of Liver

Thought of that but didn't try it.  He's been running that code long time.  Will give it a shot, but it appears the SSI.php that it's loading is a damaged file, where it's coming from is a mystery.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

drewactual

Does it use relative or absolute path?  The httpd can be configured to allow cross domain sharing on a shared server include/require, but man, is that dangerous....

There is another httpd setting that finds broken links, too... though I don't recall it's name.  Premise is if an include/require doesn't find the file it searches other directories for that file and uses it if it finds one... another bad juju on a shared host but sometimes handy on a dedicated... not that I would use it... but... its available.

Advertisement: