http://www.simplemachines.org/community/index.php?topic=373342.msg2562443#msg2562443
I don't see a way to retrieve or pass a value to $context['session_var']. This essentially breaks all interactions in regard to integration (no login, no logout, no posting, no voting in polls, etc. through integration.) This renders SSI.php pretty much useless for anything other than non-interactive display (recent topics, recent posts, etc.)
[See this post (http://www.simplemachines.org/community/index.php?topic=374064.msg2569910#msg2569910) for the procedure to reproduce it!]
As explained in the topic linked above, the behavior is the following:
In SSI pages located on different subdomain from the forum one, if you try to login with your right username and password from the ssi page login box, you are always redirected to the forum login with a "password wrong" error. Then after you have logged in from the forum, if you come back to the ssi page and you try to logout, you get a "session verification failed" error. I've noticed also that if you refresh the page the session number included in the logout link changes!!
Is there a temporary workaround? Maybe a code "downgrade" to RC2?
Please help me, my whole site is based on ssi.php!!
Thanks in advance,
Lorenzo
If I were you, I wouldn't hold my breath.
The bug is big enough that there is no quick fix. You're not going to get a small patch code to make it work.
So, the best that's going to happen is it will be fixed for 2.0 RC4. The worst case is it's never fixed.
Quote from: Orstio on April 04, 2010, 08:52:05 AM
If I were you, I wouldn't hold my breath.
The bug is big enough that there is no quick fix. You're not going to get a small patch code to make it work.
So, the best that's going to happen is it will be fixed for 2.0 RC4. The worst case is it's never fixed.
There's no way to replace the interested code with the RC2 one (that worked properly)?
Anyway.... this is a MAJOR BUG, that needs to be absolutely fixed for RC4!! I can't even see it on the bug tracker!
Most of the bugs posted here don't make it onto the bug tracker. Even the ones that do don't necessarily get fixed.
Keep in mind there are only three volunteer developers. They can't possibly keep up with it all in only their spare time.
...and about the possibility to replace the piece of code with the RC2 one (that worked properly)?
It's not just one piece of code that needs changing. As I said, it's not just a quick patch, or I would have posted one for you. It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.
Tracked as http://dev.simplemachines.org/mantis/view.php?id=4244, in order to be more easily found and considered by the devs. Also reported it directly to the people responsible with it.
Thank you both for the report and Orstio for taking the time to look into it. I will most likely not be able myself to investigate this properly soon, for lack of time and tools at my disposal for the moment, but hopefully it will be taken into consideration as soon as possible.
Quote from: Orstio on April 04, 2010, 09:25:14 AM
It's not just one piece of code that needs changing. As I said, it's not just a quick patch, or I would have posted one for you. It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.
Well, I think the idea is that it makes it harder to grab the session and reuse it since you're no longer user sesc=[session id] in the HTTP request, you also need the session variable too.
Though if you can grab one... presumably you can grab the other too. It just makes it slightly harder to notice if you're just randomly snooping.
Quote from: Arantor on April 04, 2010, 09:44:30 AM
Quote from: Orstio on April 04, 2010, 09:25:14 AM
It's not just one piece of code that needs changing. As I said, it's not just a quick patch, or I would have posted one for you. It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.
Well, I think the idea is that it makes it harder to grab the session and reuse it since you're no longer user sesc=[session id] in the HTTP request, you also need the session variable too.
Though if you can grab one... presumably you can grab the other too. It just makes it slightly harder to notice if you're just randomly snooping.
It's the same logic that makes people want to remove their copyright for "security reasons". Script-kiddies are called script-kiddies because they run automated scripts. Nobody is doing any random snooping, they are doing systematic runs of exploit checks. If $sesc could have been exploited, then the exploit should have been fixed, not obfuscated. What that says to me is that the underlying security issue is still there, it's just hidden better.
And, I agree with you -- it is harder to grab the session and reuse it. In fact, it's pretty much impossible, even from SSI.php. Thus, this bug report. See, if a security fix breaks functionality, it's what's called "throwing the baby out with the bath-water". It's like welding the doors shut on your car so nobody can get in to steal it. Unfortunately, it also means you can't get in to drive it either.
There is no point in the SSI functionality if it isn't going to work. It's bad enough that the SSI login/logout redirect bug has been around since the session fixation security fix (1.1.6?) and never fixed. Now there's an even bigger SSI.php file with even more functions, and half of them rendered useless by obfuscating a variable name.
Quote from: Orstio on April 04, 2010, 10:01:55 AM
There is no point in the SSI functionality if it isn't going to work. It's bad enough that the SSI login/logout redirect bug has been around since the session fixation security fix (1.1.6?) and never fixed. Now there's an even bigger SSI.php file with even more functions, and half of them rendered useless by obfuscating a variable name.
You're right... SSI is the strong point of SMF!!
P.S.: Thanks Norv (http://dev.simplemachines.org/mantis/view.php?id=4244)! ;)
OK, I'm able to reproduce clearly this issue. Here's the procedure:
You have a freshly installed SMF 2.0 RC3 in a /test_forum folder. Now create a subdomain, testforum.yourdomain.com (that of course has test_forum as main dir). Now change the forum url to use the subdomain. OK. Create a new folder in your server (out of the forum one), called /test_ssi. Now put there your ssi file, called myssifile.php:
<?php
// Layers to be utilized
$ssi_layers = array('html', 'body');
//This is the SSI.php file in the Board dir.
require('../test_forum/SSI.php');
?>
My test file!
<?php
ssi_shutdown();
?>
Now create another subdomain so you have testssi.yourdomain.com (with of course /test_ssi as main directory). Now clear your cookies/cache/everything and go to -> testssi.yourdomain.com/myssifile.php. You should see your ssi-based file with (of course) the login box. Now try to login, you should get the "password wrong" error and all the behaviors that we've talked about (sessions number that changes at every refresh, etc...)!
ALL THIS HAPPENS WITH THE OPTIONS "Use subdomain independent cookies" ON and "Enable local storage of cookies" OFF!
If you're on the same subdomain or without subdomains, you don't have these issues (or at least I can't reproduce 'em!).
:)
I'd like to bump this and also report another behavior I think related to this: in one of my ssi-based pages (on a different subdomain from the forum one) I use the ssi_recentTopics function, this is my code:
<?php
global $context, $settings, $scripturl, $txt;
global $user_info, $modSettings, $smcFunc, $posts;
global $color_profile;
$array = ssi_recentTopics(10, null, null, 'array');
echo '<div id="recentpost">';
$odd = false;
foreach ($array as $post)
{
echo '<div class="recentpost ', ($odd ? 'odd' : 'even'), '">
<span class="topicname" style="font-size: 85%"><strong><a href="', $post['href'], '">', $post['subject'], '</a></strong></span>
', !$post['is_new'] ? '' : '<a href="' . $scripturl . '?topic=' . $post['topic'] . '.msg' . $post['new_from'] . ';topicseen#new" rel="nofollow"><img src="' . $settings['lang_images_url'] . '/new.gif" alt="' . $txt['new'] . '" border="0" /></a>', '
<br /><small>Posted by <span class="author">', $post['poster']['link'], '</span><br /><span class="date">', $post['time'], '</span><br /><em>(Views: ', $post['views'], ' | Replies: ', $post['replies'], ')</em></small><br /><br />
</div>';
$odd = !$odd;
}
echo '
</div>';
?>
Now, sometimes (I really can't figure why this happens only sometimes) instead of going to the topic, I'm redirected to the board index!
Here's the link of one of the topic links when this happens:
http://forum.rockciclopedia.com/index.php?PHPSESSID=4e9ca3e505fdaf32d747fb9831b6d9b7&/topic,1352.msg22299/topicseen.html?PHPSESSID=4e9ca3e505fdaf32d747fb9831b6d9b7#new
(I don't have any pretty url/simplesef/topic-related mod or other strange ones, I only have seo-friendly urls enabled. I've also tried to disable tht option but this still happens!)
So, this finally seems related to the (huge) issue with sessions! :(
What do the URLs look like if you turn off SEO Friendly URLs in SMF?
Unfortunately it's not easy to reproduce this latest behavior (I really can't understand when happens)... anyway I didn't understand yet if you managed to reproduce the main (and most important) issue..:
Quote from: MultiformeIngegno on April 04, 2010, 07:53:32 PM
OK, I'm able to reproduce clearly this issue. Here's the procedure:
You have a freshly installed SMF 2.0 RC3 in a /test_forum folder. Now create a subdomain, testforum.yourdomain.com (that of course has test_forum as main dir). Now change the forum url to use the subdomain. OK. Create a new folder in your server (out of the forum one), called /test_ssi. Now put there your ssi file, called myssifile.php:
<?php
// Layers to be utilized
$ssi_layers = array('html', 'body');
//This is the SSI.php file in the Board dir.
require('../test_forum/SSI.php');
?>
My test file!
<?php
ssi_shutdown();
?>
Now create another subdomain so you have testssi.yourdomain.com (with of course /test_ssi as main directory). Now clear your cookies/cache/everything and go to -> testssi.yourdomain.com/myssifile.php. You should see your ssi-based file with (of course) the login box. Now try to login, you should get the "password wrong" error and all the behaviors that we've talked about (sessions number that changes at every refresh, etc...)!
ALL THIS HAPPENS WITH THE OPTIONS "Use subdomain independent cookies" ON and "Enable local storage of cookies" OFF!
If you're on the same subdomain or without subdomains, you don't have these issues (or at least I can't reproduce 'em!).
I managed to reproduce this in 2 different hosting and 2 different rc3 (clean) installations... You only need to install the forum in a subdomain and then create a page that calls ssi.php from a different subdomain! :)
Sorry to bump this but to help you I've created a test board to reproduce this, you can find it here:
FORUM: http://testforum.rockciclopedia.com [no more active, bug solved!]
SSI-PAGE: http://testextra.rockciclopedia.com [no more active, bug solved!]
I've created also a test-user.
To reproduce this behavior go to the SSI-PAGE (http://testextra.rockciclopedia.com), then insert this data in the header login box: "demo" & "password"
You'll receive a "password wrong" error, then try to login again always with demo & password (you're now in the forum) and it will work. Then try to logout from the ssi-page, it won't work. Instead it will work if you're in the forum.
Let me know if you need more info!
A feedback! ;D
Quote from: bluedevil on May 09, 2010, 06:40:43 PM
M, i noticed when clicking on any link in "Music News", it takes me to the forum rather than the topic. :o
I will be looking into this as soon as possible, MultiformeIngegno. Really sorry, I didn't have much time lately, but that changes every once in the while...
I think there's enough information here to understand what's going on and be able to replicate afaics. Thank you, I'm sure all this work and feedback will prove truly useful.
Oh, didn't see your reply!
Thanks Norv!! ;)
Noooooorv.....? O:) ;D
Norv has set a RC4 flag on this bug report so I guess he considers it should be fixed as a priority.
I myself had many problems in the past with subdomains, but they were mainly due to security violation when submitting forms through Ajax from one subdomain to another. Now, I don't know if this bug is related (I haven't got much time to look into it either.) Is it something that happens because the session variable can't be put into the login form from the non-forum subdomain? Or something that happens AFTER posting the form? Or non-matching session variables?
I can't even see a session var in your distant form...
BTW, your password is no longer active.
Nao, if you follow this: http://www.simplemachines.org/community/index.php?topic=374064.msg2614408#msg2614408, the problem is confirmed.
Also there's a scenario how to set it up yourself, which also confirms it: http://www.simplemachines.org/community/index.php?topic=374064.msg2569910#msg2569910
My apologies for the delay, MultiformeIngegno.
Quote from: Nao on June 07, 2010, 12:23:49 PM
Norv has set a RC4 flag on this bug report so I guess he considers it should be fixed as a priority.
8)
Quote from: Nao on June 07, 2010, 12:23:49 PM
I myself had many problems in the past with subdomains, but they were mainly due to security violation when submitting forms through Ajax from one subdomain to another. Now, I don't know if this bug is related (I haven't got much time to look into it either.)
Yeah I've read 'em (language editor), don't remember if they was similar..
Quote from: Nao on June 07, 2010, 12:23:49 PM
Is it something that happens because the session variable can't be put into the login form from the non-forum subdomain? Or something that happens AFTER posting the form? Or non-matching session variables?
I can't even see a session var in your distant form...
Look here:
http://www.simplemachines.org/community/index.php?topic=373342.msg2559905#msg2559905Sessions aren't kept properly!
Quote from: Nao on June 07, 2010, 12:23:49 PM
BTW, your password is no longer active.
Yes it is! (http://www.simplemachines.org/community/index.php?topic=374064.msg2614408#msg2614408)
:)
Quote from: Norv on June 07, 2010, 12:42:08 PM
My apologies for the delay, MultiformeIngegno.
Hey man, I always follow the development on mantis and you (and of course the other that are working on SMF) are doing an awesome job!!! Keep it up and compliments!!!!! ;)
Okay Lorenzo, I have plenty of both very good and quite bad news for ya...
- I reproduced a similar setup on my website, and managed to connect. So that's the good news.
- I don't know if the different is because it's not a totally similar setup (bad news), or because my own site fixes it (good news).
Now, my forum is in the root, so here's how I did it:
- I have a subdomain that redirects to /Themes/default/, both cookieless (http://static dot cyna dot fr) and with cookies (http://static dot noisen dot com) (I'm not putting direct links because I don't want Google to look into them. I'm a bit strange.)
- In /Themes/default/ssi_test.php, I put your code... Replacing the 'test_forum' path with '..' (i.e., "../../SSI.php"), so that it could access the proper one.
- Then I went to the cookieless version, tried to login... And I was simply redirected to the noisen.com site, without error messages, and without being logged in. This may be bad news: if I haven't got the error, maybe, maybe it's due to some weird setup on my site.
- I went to the cookie-enabled version (http://static dot noisen dot com/ssi_test.php, I trust you can type it), and tried to login. I was immediately redirected to noisen.com, *and* was logged in. Again, this may be bad news: shouldn't the login box redirect me to the original SSI page instead of the forum homepage...? The good news, though, is that I was also logged into the SSI page when I hit "back" and refreshed the SSI page.
- Then I simply clicked Logout from the SSI page, and was properly logged out from both the forum and SSI pages.
So... All in all, it's an interesting development I guess.
You may want to ask me, "how come it works on your site?"
I know it may very well be due to some reason I don't know at all, but all I can say is: because noisen.com has been running on multiple subdomains for several years now, and even though it doesn't use a single line of SSI.php code, I've be confronted MANY times with session errors due to the different subdomains.
I submitted some of them, some got fixed, etc, but all in all, I knew SMF needed to be reworked even more. So I did it on my side. This is probably the part of SMF that I hacked the most into, with many changes in variable names and such, but in the end, not only does it work, but it's been going steady for the last couple of years. I had a last bug that I fixed last year after someone complained about session problems with Firefox.
What I'd like others to do:
- Please go to that page and try logging into noisen.com (if you have an account, obviously.)
- Please confirm to me that the SSI login behavior is the same as what happens,
- Worship me, because I'm f'ing cool. Wonder at how a totally unrelated fix can sometimes help other problems,
- Discuss whether or not my fixes should be included into SMF 2.0.
*Obviously*, I have absolutely no problem sharing my code changes, and implementing them into the SVN. Let me just warn you that it's quite a large amount of code rewrites, but at least it would allow for PrettyURLs and similar URL rewriters to manage subdomains flawlessly, and would render SSI usable on subdomains as well. *And* it's been tested and re-tested for years.
NB: ever since I posted my message, the ssi_test file wouldn't work anymore. That's just because I forgot to re-upload my mint copy after trying to remove a layer from it. Sorry about that.
I also re-tried the file after removing the .htaccess (which could have had an influence over it), and it worked the same. On the very first try, though, it didn't "register" my login attempt at the board index, I don't know why. But on the second and all subsequent attempts, it did.
I've tried your test page and it works!! What does this mean? Are you able to fix SSI.php or it works because you are not using SSI.php (bad news, because means that ssi.php remains bugged)? What's the issue with the "default" sessions?
P.S.: Have you however reproduced this bug on a fresh installation? I've tried it 2 times with 2 fresh installations on 2 different hosts and I always reproduce this bug.. so it works for you due to your code changes (a good news, isn't it?).. :)
Quote from: MultiformeIngegno on June 08, 2010, 10:50:06 AM
I've tried your test page and it works!! What does this mean? Are you able to fix SSI.php
I guess I am?
Quoteor it works because you are not using SSI.php (bad news, because means that ssi.php remains bugged)? What's the issue with the "default" sessions?
I don't know.
What I know is that I've used the SSI code you asked me to use. I only changed the path to the SSI.php file.
QuoteP.S.: Have you however reproduced this bug on a fresh installation?
No. Please re-read my post. Noisen is a heavily modified forum. I've rewritten a lot of places to accept multiple subdomains in areas that PrettyURLs would usually fail to make work. (As a sidenote: I still use a custom version of PrettyURLs from 2 years ago, so it may not be compatible with my changes at all.)
I believe these changes are what helped.
Been looking into my code and it's hard to find anything that could have an influence...
There are no changes related to login in SSI.php, script.js or suspicious files in the Sources folder.
Then I thought it could be because I didn't have the sha1.js script included in my page (I don't know why it's not in my index template... But it isn't. Probably forgot to put it in while updating my theme. Is this of any security-related importance? I'm leaving it in for now.)
It's not related to the form URL either -- we both "connect" to the board index, rather than the SSI page itself.
This may be eluding all of us for a while... But in the end we'll get it right I'm sure.
Nao: I believe the sha1.js is of security implications; remember when the password is sent, assuming JS is enabled, the password is actually hashed before it's sent and sent into a different $_POST element (and the main password item is emptied)
Quote from: Arantor on June 08, 2010, 12:02:23 PM
Nao: I believe the sha1.js is of security implications; remember when the password is sent, assuming JS is enabled, the password is actually hashed before it's sent and sent into a different $_POST element (and the main password item is emptied)
Yes, but what I was wondering is whether this security issue is of the utmost importance or not. Since, well, in that case people with JS disabled would be in trouble...
Not really, all it means then that it's just sent as-is rather than hashed; think of it as one less security feature.
The research shouldn't be that big: the problem doesn't affect RC2 so it's something added/changed in RC3, at 99% the way that smf handles sessions (at every refresh of my ssi page the session number changes!).
Lorenzo, I suspect that the change between RC2 and RC3 is that the session variable name was changed from "sesc" to a random hex string. (I don't know if the change happened between RC2 and RC3, but it's likely innit?)
Now, it would be horrible if I were to discover that the reason my version works is not because of that (and a workaround I found around it), but because I haven't implemented the RC3 fix into my code... Which is quite unlikely though, as I always do my best to sync everything between noisen and the SVN. Most of my changes are in Load.php, I haven't looked into that one yet.
Nah, that change happened long before; that was in RC1 (as Orstio has noted, that was done around the time of 1.1.6)
Uhm.. so it's something else changed between rc2 and rc3..
Yup. Possibly one of the 45 vulnerabilities fixed.
I would be interested to know if the same thing is broken on 1.1.11 actually.
I'd love to have that list of 45 vulnerabilities... Or, more interestingly, the list of changes they represent.
Really need to find a way to pinpoint how I 'fixed' it on my site!
@arantor: aren't they listed on mantis (maybe as "private")?
No, they're not. They're on another site. Since it's an active list of vulnerabilities, I'm not sharing it on this forum. I have notified Nao of the link, though, and I believe the dev team is aware of it. In fact, they're due a visit from Marketing over breaching SMF's licence...
Yeah, interesting breach... Although I don't know if at this point, it matters much at all. (No details needed.)
As for the security issues, I'm afraid I don't have enough time to look into them for now. FWIW, most of them are probably dummy. Right now I'd rather focus on my bug list in Mantis. I'm making progress on a few of them.
All of the issues on that list should have been fixed in RC3.
Oh... Good then. I don't think you told me 'bout that ;)
So, back to the session_var issue now...
Could more people please confirm that my own version of the SSI file is working? (And again no, it's not something in SSI.php that magically fixes it... None of the changes are related to sessions and login.)
I've tried with different browsers and it works..
Team... We should be discussing the possibility of moving SMF2 to my own subdomain-handling system, shouldn't we?
If it works like it sounds like it should and doesn't add any security issues (i.e. makes it easier to grab the session id, or permit session fixation) I'm all for it since this is a blocker for one project (though a distant one, plenty of stuff to worry about before this becomes an actual issue)
Also Sinan should be interested to this, I've noticed that it affects also simpleportal in standalone mode with the portal in another subdomain (every time you try to login from the portal you get the 'password wrong' error)!
*starts to read all the thread, but decides to ask meanwhile, just in case*
Did we discover what exactly was/were the issue(s) here? :)
So far, no...
What we have is:
- Plenty of things were tried, without success
- We know nearly for sure that it works on noisen.com
- I've analyzed the code differences between RC2 and RC3 and couldn't find anything suspicious related to sessions,
- I've analyzed pretty much all of the code differences between noisen and RC3 (this took me easily 3 hours today), and unfortunately, didn't find anything either. (In the process I made a few fixes for other things, which I committed to rev 9959 I believe.)
I've done other changes I haven't committed, in the hope that they could be related, but first of all I'll have to install a new subdomain for use with my clean copy of rc3. I'm also waiting on feedback from Lorenzo (I asked him for FTP access to be able to trace through his code, in case the problem doesn't happen on my clean copy.)
Ah, and finally -- the biggest issue right now is with my server: it was down for 3 hours this morning because of CPU abuse. I think I've had an attack or something, because I actually had less traffic according to my stats... So, I've been discussing with a friend and I'll be moving noisen.com to a new server. Hopefully it won't take too much time to do.
Quote from: Nao on June 09, 2010, 02:20:07 PM
I'm also waiting on feedback from Lorenzo (I asked him for FTP access to be able to trace through his code, in case the problem doesn't happen on my clean copy.)
Sent! ;)
I knew this was going to be trouble. But hey, you wanted it, you didn't have to take the hardest bug on our list for yourself, that's ... selfish, I say! :D :D :D
I just have this feeling you kinda like the challenge...
(sorry to hear about your server btw)
@Lorenzo> Got it... Will look into it tomorrow. Tonight I... I was...
I was watching Glee. OMG people are gonna throw eggs at me now. My girlfriend made me do it, I swear!Quote from: Norv on June 09, 2010, 02:43:45 PM
I knew this was going to be trouble. But hey, you wanted it, you didn't have to take the hardest bug on our list for yourself, that's ... selfish, I say! :D :D :D
Oh... I'm pretty sure there are harder bugs than this one!
Heck, I haven't even looked at the entire list of 60 bugs. I always have trouble keeping up.
QuoteI just have this feeling you kinda like the challenge...
Not really... What I like is when I beat it, eheh.
I only hope that it's not a false hope we have here: (1) specific server configuration or (2) a 'fix' that introduces (or cancels out) another security fix.
Quote(sorry to hear about your server btw)
Well, it was long overdue I guess... I just would have appreciated that it crashed in April instead, back when I was living the sweet days of not having to work on SMF. ::)
Quote from: Nao on June 09, 2010, 06:12:50 PM
I only hope that it's not a false hope we have here: (1) specific server configuration or (2) a 'fix' that introduces (or cancels out) another security fix.
I've tried it on another server/host and I reproduced the same behavior.. :(
Quote from: Nao on June 09, 2010, 06:12:50 PM
I was watching Glee. OMG people are gonna throw eggs at me now. My girlfriend made me do it, I swear!
Hahahah!! ;D
I'm dead!!!
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.)
(And I can't wait till I get to that Joss Whedon episode.)
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. [...]
Well.. it's a bad/good news... Bad because means it's definitely a bug, good because you can analyze it better! :)
Okay.... Some more news. Could be good for you (a fix) and bad for me (no way to determine what causes the fix.)
Yesterday, I didn't spend a LOT of time on this bug, I simply made sure to reproduce the setup exactly, etc, made several attempts, then upgraded my test site to the latest SVN, noticed a few glitches and switched to fixing other issues.
This morning -- I'm back on it. Took me some time to get my mind ready because, well... It's a big one.
So... I went to http://ssi dot geez dot fr/ and typed in my user name & password to get the error to happen again and check some logs.
It frigging worked.
Went back to the SSI page, refreshed: was logged in. Clicked logout: was logged out without issues.
Okay... Here's the thing. *I didn't change anything to it*!!!
All I did was upgrade my SVN copy from May 28 to June 9 just so I could test my changes. That's all!
So. Did I fix the bug recently without noticing? I don't think so. Did I fix it in the SVN these last few weeks in an unrelated fix, and forgot to upload related files to my site? Unlikely, but possible.
I tried with IE8, same thing. It worked...
I tried with Chrome, which I'd never used on geez dot fr, and it worked, so it means it is not something that magically fixes itself after several login attempts.
Can you confirm, Lorenzo?
To anyone else: did you recently (i.e. less than a month) try to reproduce the bug on your test setups, with similar results? Did you retry recently? (i.e. these last few days)
It doesn't fix automatically.. it's since I upgraded to rc3 from rc2 that I reproduce it (every browser, also in "private mode" so cache is empty) and it never fixes magically!
Another test you can try: call boardNews in the ssi page (display the latest topic from a board), then visit the ssi page when you're logged in, links will work as expected and will bring you to the right topic. Then logout and visit the ssi page again. You should notify that boardNews links are not working and you're redirected to the board index instead of the expected topic. This behavior is related to this bug because if you take a look at the boardNews links (ONLY IF YOU'RE LOGGED OUT), they are "strange"..
Sorry if my explanation isn't clear but it's difficult to explain! :P
Quote from: MultiformeIngegno on June 11, 2010, 06:54:04 AM
It doesn't fix automatically.. it's since I upgraded to rc3 from rc2 that I reproduce it (every browser, also in "private mode" so cache is empty) and it never fixes magically!
You didn't tell me if ssi dot geez dot fr works for you now...?
Quote from: Nao on June 11, 2010, 07:12:50 AM
Quote from: MultiformeIngegno on June 11, 2010, 06:54:04 AM
It doesn't fix automatically.. it's since I upgraded to rc3 from rc2 that I reproduce it (every browser, also in "private mode" so cache is empty) and it never fixes magically!
You didn't tell me if ssi dot geez dot fr works for you now...?
I've tried to register but registration is disabled.. is there a test user?
Sorry, forgot about that... test / lorenzo
Quote from: Nao on June 11, 2010, 08:58:21 AM
Sorry, forgot about that... test / lorenzo
Great!! Works for me! 8) ;)
If you try this we can see if this has been fixed too:
Quote from: MultiformeIngegno on June 11, 2010, 06:54:04 AM
Another test you can try: call boardNews in the ssi page (display the latest topic from a board), then visit the ssi page when you're logged in, links will work as expected and will bring you to the right topic. Then logout and visit the ssi page again. You should notify that boardNews links are not working and you're redirected to the board index instead of the expected topic. This behavior is related to this bug because if you take a look at the boardNews links (ONLY IF YOU'RE LOGGED OUT), they are "strange"..
I added simply ssi_boardNews() and everything works for me...
I guess I'll have to look into your site!
Quote from: Nao on June 11, 2010, 09:15:00 AM
I guess I'll have to look into your site!
FTP details I "PMmed" you still work! ;)
You can reproduce this behavior by visiting www dot rockciclopedia dot com and clicking one of these links:
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fimg191.imageshack.us%2Fimg191%2F9035%2Fboardnews.jpg&hash=ab508527dbe72ec8b5025b711f77149bccbfef7d)
This is the urls structure:
http:*/forum dot rockciclopedia dot com/index.php?PHPSESSID=5c6df767585c2ca044f958a845773385&/topic,xxxx.0.html?PHPSESSID=5c6df767585c2ca044f958a845773385
There's phpsessid twice!
And here is the code (boardNews):
$array = ssi_boardNews(5, 7, null, 570, 'array');
foreach ($array as $key => $news)
{
if ($key == 0)
{
echo '
<a href="', $news['href'], '"><big><strong>', $news['subject'], '</strong></big></a>
<br />', $news['body'], '<br /><hr />';
}
else
{
if($key == 1)
echo '<center><a href="http://extra.rockciclopedia.com/feed.php"><strong><img width="11px" src="http://www.rockciclopedia.com/images/rss_icon.png" alt="*" /> <font color="white">Iscriviti al feed rss</font></strong></a> <span style="visibility: hidden;">-----------</span><a href="http://forum.rockciclopedia.com/index.php?action=post;board=5.0"><strong><img width="11px" src="http://www.rockciclopedia.com/images/news.png" alt="*" /> <font color="white">Segnalaci una news</font></strong></a></center><hr />';
echo '
<a href="', $news['href'], '"><font style="font-size: 1.1em"><strong>', $news['subject'], '</strong></font><img src="', str_replace(';preview', ';thumb', $news['image']), '" alt="', $news['subject'], '" style="float: right; margin-top:2px; margin-left: 5px;" height="54px" /></a> <span style="color:#666">(<small>', date('d/m/Y', $news['timestamp']), '</small>)</span> <br />', shorten_subject(strip_tags($news['body']), 130), '<br /><hr style="margin-top: 15px; margin-bottom: 5px;" />';
}
}
Err... You sure?
I'm not logged in, and the kind of URL it gives me is:
http://forum.rockciclopedia.com/index.php/topic,1397.0.html
Honestly.
Weird!!!! :(
I've tried with Firefox, Chrome and IE..
Here's a screen:
http://img192.imageshack.us/img192/9328/boardnews2.jpg
Uhm.. I don't know.. Try using a cache-clean browser...
P.S.: The svn at ssi dot geez dot fr does contain your fixes from noisen or it's simply the latest rev and you don't know why it works?
1/ I'm using Opera... And it's clean. It has much better cache handling than the competition. It's not a leftover or anything. This is probably because I have a PHPSESSID cookie that is set. The first time you visit a website, you can't immediately get a session cookie. The session is created, and the page is sent to you as is. If your cookie feature is disabled, then let's say you logged into a site -- you'll see yourself as logged, and next time you refresh the page, you're logged off. This is the same here: the first time you come to a site, you don't have a session cookie, so a temporary session is created, with ID stored in PHPSESSID, and this is sent to you. The next time you reload the page, you should have the session in your cookie, and no PHPSESSID in links. It's always like that.
Maybe your own browser has cookies disabled or something?
2/ My geez test site has the latest revision, yes. There is no "intended" fix in it. That's why I'm stumped. It didn't work with the May 28 revision, then I updated it to the June 9 revision and it started working. However, once again: there is no visible change in the last 2 weeks that is directly related to sessions. I committed most of the changes in these last two weeks, so it's likely that I added a fix from noisen.com while fixing some other bug. But what fix, really? I don't know...
Quote from: Nao on June 11, 2010, 10:41:55 AM
Maybe your own browser has cookies disabled or something?
No, I'm sure! I've seen this behavior also with different browsers in different OS/computers (one with Mac OSX too)!
So it's simply.. weird!! xD
Quote from: Nao on June 11, 2010, 10:41:55 AM
2/ My geez test site has the latest revision, yes. There is no "intended" fix in it. That's why I'm stumped. It didn't work with the May 28 revision, then I updated it to the June 9 revision and it started working. However, once again: there is no visible change in the last 2 weeks that is directly related to sessions. I committed most of the changes in these last two weeks, so it's likely that I added a fix from noisen.com while fixing some other bug. But what fix, really? I don't know...
Uhm... should be useful to see if it fixes the problem on my site..
Okay, I'm getting a backup from my geez site and will compare the files manually...
After a painful backup retrieval session (it kept logging off the ftp server >_<), I got to compare the files... STILL no obvious change to me. Then it struck me, okay I'll just reinstall the version that didn't work... AND IT STILL WORKS. (Try it out, it's the old version that's online now.)
So, maybe.................... Maybe it isn't a SMF code problem at all! But WHAT ELSE, then?!
This thing is going to be the death of me...
I really have no idea.. I only know that with RC2 it worked! :(
The strange thing is that your setup sometimes works, sometimes not.. in my site (and also the test (http://testextra.rockciclopedia.com) setup, username: demo, password: password) it always does not work!
Okay, I'm reinstalling a fresh RC3 in its place...
So far so bad. I've uploaded all of the contents of Themes and Sources, and it still works.
Just can't reproduce now.
I tried on your test site again, and reproduced, so I'll be working on that one I guess...
What a weird bug! :(
Nao did you manage to connect to my site with the new ftp details? :)
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.
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 (http://bugs.php.net/bug.php?id=43682), often leads different subdomains to return a different session_var when using the same PHPSESSID. Sounds familiar?
ini_set("suhosin.session.cryptdocroot", "Off");
ini_set("suhosin.cookie.cryptdocroot", "Off");
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.)
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,
Hopefully they'll be quick, because... well, I can't wait to see?
Quotebut... didn't you reproduce it on your server too?
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! :)
NAO YOU DESERVE A STATUE!!!
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fimg22.imageshack.us%2Fimg22%2F2782%2Fnaostatue.png&hash=6392cb4ccbd90f34798a2ba66297fa01b0bda5c1)
They've disabled the patch and everything works flawlessly!!!!!!!!!
P.S.: Now let's leave in peace the poor Nao ( :P ) and let's ask the other devs: we've discovered the problem, and insured it's not a SMF problem.. anyway is there a way to "avoid" this? Maybe a workaround that applies if SMF detects you have that configuration.. Are there many server with that patch installed?
Quote from: MultiformeIngegno on June 14, 2010, 05:35:09 AM
OK man... you're right (as always). Also with SMF 2.0 RC2 it doesn't work.
You..........should have tried that......earlier......... :o
It would have saved me several hours of comparing RC2 and RC3 code last week...
QuoteI've opened a ticket, hopefully they'll disable the patch or.. don't know.. they're always kind! :)
Just ask them to disable the two variables I mentioned. *Or* to tell you how to disable them via php.ini or .htaccess, because normally, their access level SHOULD allow you to disable them, but I tried and tried, and it never worked.
Quote from: MultiformeIngegno on June 14, 2010, 06:17:39 AM
NAO YOU DESERVE A STATUE!!!
Lulz!!1
QuoteThey've disabled the patch and everything works flawlessly!!!!!!!!!
Just the two variables, or the entire Suhosin?
QuoteP.S.: Now let's leave in peace the poor Nao ( :P ) and let's ask the other devs: we've discovered the problem, and insured it's not a SMF problem.. anyway is there a way to "avoid" this? Maybe a workaround that applies if SMF detects you have that configuration.. Are there many server with that patch installed?
Yes, Suhosin is pretty popular in the shared hosting world I believe. It's a way of closing some potential PHP holes I believe.
As for the cryptdocroot variable, I have no idea whether it's enabled by default or not.
The only way to fix it through SMF is to ini_set the two variables to Off. I've tested this on my server (which doesn't have them) and it didn't generate any issue, so it should be safe enough. As for security, I don't think disabling it would cause any trouble. Maybe disable them only if the loadSession() variable is called through SSI.php...? That may be a good solution, although not perfect (because with some code hacking, subdomains can be used on any SMF page, see noisen.com, so that wouldn't help SMF in case we implement the feature into v2.1 or v3.0.)
Quote from: Nao on June 14, 2010, 07:24:15 AM
QuoteThey've disabled the patch and everything works flawlessly!!!!!!!!!
Just the two variables, or the entire Suhosin?
Quote
Hello Lorenzo,
Sorry to hear about this. The SuHosin configuration we were running was the default one, however we hadn't realised that the default configuration could cause this kind of problem.
We've gone ahead and disabled suhosin.session.cryptdocroot and suhosin.cookie.cryptdocroot now (as can be seen under the "suhosin" heading of this phpinfo() page: http://devotedhosting.com/phpInfo1492.php )
Hopefully this problem should now be resolved (Googling this issue does show a few people having a similar problem with subdomain script linking, when this setting is on). Please let us know if you need any other settings changed however :)
Many thanks!
Good, good. BTW, googling devotedhosting brings me to a SMF beta tester's signature... So I can only guess they were indeed eager to help ;)
The bad news is that the setting is On by default, then. And if everything's the default setting, then it can't be turned off by SMF either. Maybe this will need a mention in an FAQ or something.
Norv, you're the assignee for the bug report -- how would you like us to deal with it?
*reads around the suhosin doc (http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptdocroot) and other reported cases (http://www.sitepoint.com/forums/showthread.php?t=448977) on the net.*
Oh darn. Thank you Nao! This was a good one! :)
Thank you for the time put in it.
I don't think it's much SMF can do, it seems to me rather rare, I think. The domain/subdomains should be set up as different virtual hosts in the apache/lighttpd configuration files (so with different docroot); the session encryption key set in suhosin configuration to depend on docroot...
I do tend to think it should be documented, in our doc about SSI/other integrations, because afaics that's what it might interfere with.
Yeah, it's sad that it can't be fixed once and for all within SMF.
I'll leave the rest to you.
I'm currently focusing on my remaining bugs. (And reading your PMs.... :P)
Is this considered a candidate as a valid bug, as it's quite an involved issue and heavily server config related?
Closing old 2.0 bugs - 2.0 is in security fixes-only at this point.