SMF Development > Bug Reports

[4244]SMF 2.0 RC3 - Obfuscation of session variable name breaks integration

<< < (16/18) > >>

Nao 尚:
I didn't try yet. Not only wasn't I online today, but I'm pretty dried out when it comes to SMF right now. Dunno what I'll do about it.

Nao 尚:
Okay...... Here are my findings over this last week. I'm pretty confident I've nailed the problem, and I'm also very confident it can hardly be fixed.

- I traced back the issue to loadSession(), which as it says, loads the current session.
- Normally, this function should return the same session_var for both subdomains. It doesn't. However, the PHPSESSID is indeed the same for both subdomains, meaning it really SHOULD be returning the same session_var.
- Now, armed with much patience, I did an ini_get_all() on your server and compared it with my server's. Basically, they're very close, except for two things:
1/ session.use_trans_sid is set to 0 on your server, and 1 on mine. Since SMF disables it, it shouldn't be the origin of the problem. May still be worth looking into.
2/ your server has the Suhosin patch installed, with, take very careful note, suhosin.cookie.cryptdocroot and suhosin.session.cryptdocroot set to 1. This behavior, according to this website, often leads different subdomains to return a different session_var when using the same PHPSESSID. Sounds familiar?

--- Code: ---ini_set("suhosin.session.cryptdocroot", "Off");
ini_set("suhosin.cookie.cryptdocroot", "Off");
--- End code ---

So, I tried to apply the link's solution (see above) and disable the suhosin variables, but your server refuses it. It gives an access of 6, which means it can be overridden in php.ini or .htaccess, but not with a script. I tried both .htaccess and php.ini (I've left the php.ini online for you to see), and it STILL does not change the value of these variables. Now you'll have to ask your host to try and disable these two variables manually via their master php.ini or httpd.conf!
If it still doesn't work, ask them to try and revert the session.use_trans_sid variable.

Finally, if it STILL doesn't work, just try with another host.

I officially will NO longer work myself on that bug. It has eaten 80% of my week (mainly trying to reproduce the bug on various setups), and it's now quite obvious to me that it's something specific to a badly configured server. (Or a bug in PHP, which in any case, means it's NOT SMF's fault.)

PS: loadSession() is the same in both RC2 and RC3, so there's no reason your RC2 should have worked any better. Try again (like, install yet another test copy of SMF RC2 in a folder inside the subdomain), but I very much doubt it will work at all.

Thanks for your really useful info and your time spent on this! ;)
I'll ask my host if they can help me, but... didn't you reproduce it on your server too?

--- Quote from: Nao on June 09, 2010, 06:49:36 PM ---Oh, btw, I reproduced the bug on a fresh install of the latest svn, with two different subdomains, using the same setup (ie the SSI subdomain is in a folder inside the main subdomain.)
So, it's definitely not a problem with your server. It'll be easier for me to deal with (as it's a test server), I won't be needing your ftp details again. (I only use other people's ftp details as a last resort.)

--- End quote ---

Nao 尚:

--- Quote from: MultiformeIngegno on June 14, 2010, 04:57:53 AM ---Thanks for your really useful info and your time spent on this! ;)
I'll ask my host if they can help me,
--- End quote ---
Hopefully they'll be quick, because... well, I can't wait to see?

--- Quote ---but... didn't you reproduce it on your server too?
--- End quote ---
Yes, but remember? It fixed itself... So it may have been a different problem, something like a cookie not setting itself properly or whatever. I'll probably never know why it happened in the first place. Thing is, I did try to reset the website to how it was when I reproduced the bug, and it didn't happen again, so it's not something due to a change in the code.
Also, if you can try installing RC2 on a testforum2 subdomain and your SSI file in testextra2, and show me that it DOES work this time, then I'll spend an extra day tracing through it.

PS: It's not actual "tracing", because tracing involves having a local server+debugger, and I don't use that kind of thing (I probably would have installed one if the bug could have been reproduced anywhere), so it takes a lot more time because it involves putting print_r and echo calls everywhere in the code to check how it evolves. Really NOT funny at all... Just look at me this morning, I'm a complete mess. I received 6 or 7 PMs from my team leader and have yet to answer any one of them.

OK man... you're right (as always). Also with SMF 2.0 RC2 it doesn't work.
I've opened a ticket, hopefully they'll disable the patch or.. don't know.. they're always kind! :)


[0] Message Index

[#] Next page

[*] Previous page

Go to full version