|
Post by marchantblue on Aug 15, 2007 2:25:43 GMT -5
I've been running 1.21b for a long time now and haven't made the switch due to hassle, but it's acting up sufficiently (strange, unknown 404 errors every time I try to edit an entry) that I felt I'd upgrade.
I tried to install 1.7.3, but I'm having some trouble. I went ahead and did a full, clean install. I copied all of the settings over that worked with the old version. However, when I try to run Diagnostics & Repair for the first time, I get: "We don't take kindly to that sort of activity here. Your attempt to break the script has been logged and the administrators have been notified."
At first, I thought it might be an issue with an old Perl, but my webhost informed me that they're using 5.8 on an Apache server. In attempts to narrow down the problem, I installed 1.6.1 without any trouble (Diagnostics & Repair worked fine with the same settings). However, I'd like to have a lot of the new anti-spam features of the latest version.
I looked through the forums and didn't notice anyone with the same problem, but does anyone got any ideas on what's going wrong?
|
|
|
Post by coldstone on Aug 15, 2007 17:05:55 GMT -5
Not sure if this will make a difference, but you can't do a clean install and then copy over configs from 1.21 (or any config before 1.6.1).
The format of gm-configs, gm-templates, gm-counter files were all changed in the 1.6.1 release. You must use the upgrade process for those files to work correctly. With your 1.6.1 install, do your configurations look ok?
|
|
|
Post by marchantblue on Aug 17, 2007 4:10:27 GMT -5
I think I was a little unclear. I have an old install of 1.21b that's starting to get buggy. In a new directory, I attempted a clean install of 1.7.3.
By copying the settings, I meant that during the config of the 1.7.3 clean install, I made sure that all of the same settings (paths and things of that nature) matched up (on each config screen)...just with the new directory name substituted. Unable to get that diagnostics/repair (1.7.3) to work, I deleted it and made a clean install of 1.6.1. I made sure that the paths in that matched those from my 1.21b (with the exception of the new directory name). That diagnostic/repair (1.6.1) ran fine.
So yeah, no files have been copied over others or anything like that.
Oh...maybe I get what you're hinting at...seeing as the 1.6.1 works correctly, I could go through the upgrade process on it to get to 1.7.3 since I can't get the clean 1.7.3 to work?
Failing that, I can point you to my install attempt if that'd be helpful.
|
|
|
Post by coldstone on Aug 17, 2007 17:04:24 GMT -5
I was thinking you had just copied over your gm-configs.cgi, etc. to your fresh install. I am following you now.
A fresh install should not trigger that kind of error, so that worries me. I would be interested in looking around your 1.7.3 install if thats ok.
Are the paths exactly the same between your 1.6.1 and your 1.7.3? I hate to have you upgrade to 1.7.3, but you can try it. 1.7.3 should work out of the box.
|
|
|
Post by marchantblue on Aug 20, 2007 15:10:23 GMT -5
I'm out of town for a couple of days and don't have all of the necessary files and software with me. However, when I get home, I'll set it up and let you give it a look. All of the paths were essentially the same (different directory name is all).
|
|
|
Post by coldstone on Aug 21, 2007 17:25:27 GMT -5
I was wondering though, do your paths have '../' in them (local paths)?
|
|
|
Post by marchantblue on Aug 29, 2007 8:42:47 GMT -5
I was wondering though, do your paths have '../' in them (local paths)? Yes, they do. I just tried the "upgrade" route (clean install of 1.6.1 to 1.7.3 upgrade) and no luck. Still getting that same error when I try D&R. If you want to take a look at it to see if you can figure out what's wrong: domain: www.ccs00.comdir: cgi-bin sub-dir: chronicles file: gm.cgi l/p:Alice/wonderland Again, those paths that are set work fine for 1.21b and 1.6.1.
|
|
|
Post by coldstone on Aug 30, 2007 0:30:00 GMT -5
I can tell you right now, its not liking the '../' in the paths. In an effort to make Greymatter more secure, we scan files that are trying to be saved. One of the sneaky things malicious people do is try to trick a program into saving over a file by using relative paths.
I know this isn't documented well (and the instructions on the page still say you can use local paths). Basically, if you replace those first three paths with the full paths (example, /user/coldstone/htdocs/). Everything should work fine then. If you are having trouble figuring out the path, there is a pwd.cgi on the forums that can tell you the information.
In fact a fresh install of Greymatter will automatically populate those fields with very good guesses as to your paths.
|
|
|
Post by marchantblue on Sept 5, 2007 3:08:07 GMT -5
Okay...the install is working fine...I appreciate all of the help so far.
However, after I imported my old archives, I'm experiencing a similar error to what I was previously going through. This leads me to believe that there's some sort of corruption in some of the entries, but I can't figure out what the hell it is.
Most of my entries work fine when I go to the 'Edit Entry'. However, on a number of them, whenever I click any of the buttons (Save/Return to Main Menu/etc), it sends me to an HTTP 404 Not Found page instead of performing the action. A lot of the most recent entries do this. Thinking it might've been something chronological, I dug through the archives.
It seems to be slightly random though. For example...
Entry #125 has the error. Entries #126-127 do not. Entries #128-131 have the error.
I'm comparing the cgi files of "good" entries and the error-prone ones, and I can't see any differences aside from content. Nor can I see difference in the individual html files. I also can't find discrepancies in gm-entrylist.cgi. Is there another place I should be checking?
Oh...let me add that when this problem starting cropping up a few weeks ago, I was going through my cp log/entry edits/spam deletion in the old version and had a very fishy 'hi' error message pop up at one point.
Alice/wonderland is re-enabled if you want to take a look at it.
One other thing that I've noticed...GM doesn't seem to be immediately picking up on the fact that there are a bunch of entries in the archives. Like, since I re-copied gm-entrylist.cgi, it recognizes them in the edit list, but when I rebuild everything, it's not automatically rebuilding all of them (I'm having to individually rebuild each entry through the edit page). Finally, I notice that {{logbody}} is only pointing to my first entry for my main-index page. Was there more necessary for the archive transplant than I assumed?
Edit: Last paragraph resolved after running Diagnostics & Repair. =)
|
|
|
Post by coldstone on Sept 5, 2007 17:24:24 GMT -5
Yeah, D&R with rebuild both the gm-entrylist.cgi and the gm-counter.cgi.
I will try to take a look, but I am guessing there is something in the data, maybe not a bad character but a missing date field. If its not too long, can you post your gm-entrylist.cgi? Otherwise feel free to pm it to me.
|
|
|
Post by coldstone on Sept 7, 2007 16:46:46 GMT -5
General Update. Working with merchantblue, it was discovered that 'a...b' was causing the issue with saving the entry. Changing it to 'a... b' fixed the issue (notice the space before b).
Research into why this happens is still ongoing.
|
|
|
Post by Carlos Phelps on Sept 7, 2007 17:02:42 GMT -5
Coldstone,
I believe the 'a...b' would make a series and with a few other keycodes could make a hack, but if it's in a single quoted q{} field nothing should happen and would not be a risk.
|
|
|
Post by marchantblue on Sept 8, 2007 10:57:32 GMT -5
Ha. That is excellent news. Sadly, I use this style of writing quite frequently...but no worries. I can adjust to adding a space. =)
So I went through the entries and fixed all of those issues. It fixed some of the entries, but others still have the glitch. I noticed that the same error doesn't occur in every entry with the ...(lacking a space).
In the process, I narrowed down another issue. Apparently, if the word 'poker' appears anywhere in the text...the appearance of a url (in an image tag, link tag, etc) anywhere after it will cause the same error.
This really leads me to believe that there's some sort of virus infecting the server of my webhost...that results in this error when specific text strings show up.
I do feel like progress is being made in the issue. I just need to uncover all of the text strings...and ideally figure out where the "infection" is.
'casino' also appears to be a trigger string.
Would my webhost have implemented this for some reason to keep their customers from linking/hosting to gambling?
Just did a "Search & Replace" across all of my entries, substituting 'p-game' for 'poker' and 'resort' for 'casino'. All of the entries work now. Kind of ridiculous...and a little unfortunate since poker was my career for a couple of years, but oh well.
|
|
|
Post by Carlos Phelps on Sept 8, 2007 12:11:01 GMT -5
|
|
|
Post by coldstone on Sept 10, 2007 17:21:13 GMT -5
Its easy for me to point at your host, but now that you point out the poker+casino issue, I bet your host is scanning the data coming to its servers and stopping it from running, which fits the pattern of another user on the forums. Her host was giving the 404 error everytime she tried to update her templates with javascript. The server was rejecting any request with '<script' in it. But it denied knowledge of this
|
|