Migration issues

[tomreyn]

Hi,

we recently migrated a long grown SMF installation from one domain to another, changing a lot of stuff under the hood in the meantime. Most things are working well on the new site now, but some issues remain, and we're unsure about the cause, so I'm looking for your insight.

The host:
The old host (migration source), hXXp://glest.org/glest_board_archive/, runs Apache 2.x with PHP (I assume via mod_php). The database backend is MySQL 5.5 community edition with MYISAM tables. It is running SMF 2.0.3
The new host (migration target), hXXps://forum.megaglest.org, runs Nginx 1.2.1 with FastCGI connecting, via Unix sockets, to a daemonized PHP-FPM 5.3.22 and XCache. The new host makes the forum available via HTTPS only (after all authentication takes place there).  The database backend is Percona MySQL Server 5.5 with InnoDB tables. It is running SMF 2.0.4.

Mods:
The following mods are installed on the new forum and were installed on the old one, too.
1. httpBL    2.5.1
2. Spoiler Tag    0.7.2a
3. Honeypot    1.0 - custom mod which only places the honeypot script on the server.
4. Stop Spammer    2.3.9
5. KeyCAPTCHA for SMF    2.5
6. Wikipedia BBC    1.0
7. YouTube BBCode    2.6
8. Extended Formatting BBCode    1.0 - custom mod which adds a few basic BBCode: h1=style, h2=style, h3=style, float=right|left, and formatted table codes (same as the regular table stuff, but with an "f" in front) ftable, ftr, fth, and ftd). Demo at hXXps://forum.megaglest.org/index.php?topic=8942.msg87100#msg87100

We also use a custom theme (?theme=5), but all of these issues can be reproduced with the default SMF 2.0.4 theme (?theme=1).

The migration:
We started out by doing a complete 2.0.4 nstallation on the new host, then copied back files from the old system one by one, taking note of the differences mods had made to them. We restored the database dump and converted all tables to InnoDB, then optimized them. We edited Settings.php and also used some script provided here to edit installation paths stored in the database (I forgot the exact name, but assume you can tell by the description). We then adjusted the configuration using the Admin web interface. Some more fiddling was needed to get HTTPS working properly and securely. Forum cookies were set to be "secure". Caching is on level 1.

The issues:

• Post preview: only works when Javascript is disabled (you are then posting a complete HTML form, not using a XMLHTTP request). With javascript on, you'll only get the word "Fetching...".
• Post quick edit: depends on Javascript, and never works
• Topic title quick edit (forum view): Only shows "Loading" bar on top of the screen.
• In addition to the boards configurable cookie (cookie name, domain contraints, secure) which already contians a session ID, there is another cookie set which is just using the default name of PHPSESSION, contians a session ID, can't be configured, and is not / cannot seem to be restricted 'secure' or 'httponly'. We tried to determine where this is actually set but it's hard to tell, not knowing the source code well.

Regarding the first three issues (maybe just the first two), we were able to trace thiese issues back to a blank space which sits in front of the XML doctype declaration in the XMLHTTP response. Example: hXXps://forum.megaglest.org/index.php?action=quotefast;quote=85750;modify;xml
It is unclear, though, where this blank space stems from, and whether this may be a bug in SMF or one of the mods. We can rule out that it is theme related.

Thanks a bunch in advance for any hints you can provide us with.

PS: Sorry about those hXXp(s) links, I'm not allowed to post them properly, yet.

Update 1: Added info on custom mods.

[Arantor]

Regarding the first three issues (maybe just the first two)

That sounds like all three. Check every .php file for spaces before or after the <?php and ?> tags.

We can rule out that it is theme related.

Can we? I wouldn't. I'd check every single file, especially since index.template.php will be loaded anyway and all language files are stored in the theme area...

Also check to make sure that there's no UTF-8 BOM on the files, shouldn't be but worth checking. Decent text editors (like Notepad++) can tell you this.

In addition to the boards configurable cookie (cookie name, domain contraints, secure) which already contians a session ID

That would be PHP's fault. Even if you do your own handling, PHP still creates this. SMF does not use it at all except for guests and then only to figure out how many 'unique' guests there are at once, it is of no security consequence.

[The Omega]

One of the other admins on Tomreyn's board, here. It was indeed an issue with a space outside the PHP closing tags. In particular, the PHP file included in the Wikipedia_BBCode package has a trailing space. Removing that fixed the problem. Thanks for your help.

[tomreyn]

Awesome, thanks for the quick and complete help, Arantor!

In addition to the boards configurable cookie (cookie name, domain contraints, secure) which already contains a session ID

That would be PHP's fault. Even if you do your own handling, PHP still creates this. SMF does not use it at all except for guests and then only to figure out how many 'unique' guests there are at once, it is of no security consequence.

So I guess you are saying that it does use it. I just learnt how to enforce retrictions on this default PHP session cookie using php.ini settings (session.*), which is done now. It should be noted that the default session cookie storage location is on-disk (session.save_handler=file), and this can surely negatively impact performance.

[Arantor]

So I guess you are saying that it does use it.

It does, but the consequences are not for security reasons. I have in the past mooted removing it entirely and disregarding the number of 'guests' online at once for it is a silly number that bears little real similarity to reality.

It should be noted that the default session cookie storage location is on-disk (session.save_handler=file), and this can surely negatively impact performance.

That's been PHP's default since forever since not every host allows for alternatives. SMF does its own cookie saving through the database - but note that cookie storage location is something in its own right as compared to what the cookies are called or how they are used

Mind you the reason SMF does that is not performance, but security.

[tomreyn]

Thanks for those replies, too. And in case you, once again, feel like trying "a new game every day", may I suggest you take a look at MegaGlest (the free and open source game our forum is about).