0.5.3 Public Beta Testing

[Nick]

This release has a number of new features and a few updates to the rest of the script.

Fixes since 0.5.2:
- Updated the page encoding function to preserve <script> blocks if browsing with Internet Explorer. This is still not fully tested but appears to have fixed the previous problem where IE would refuse to run scripts or generally do strange things such as moving Adsense banners around. I've only tested in IE7 (and of course Firefox), other browsers may still be faulty.

Features:
- Unique URLs generate unrecognisable proxified URLs. This includes a random - i.e. may or may not be done for each user - str_rot13() and strrev(), as well as adding a salt to prevent base64 decoding. The javascript parser has also been updated to generate URLs in this format if desired. To create links to a proxified URL in your theme you must use the proxifyURL() function to take into account the "uniqueness".
- Path info URLs further disguise the script by changing browse.php?u=aHR0cDovL3d3d...&b=61 to browse.php/aHR0cDo/vL3d3d/b61/. This requires that the server loads browse.php when a request of this format is made and passes everything after the filename to the script in the $_SERVER['PATH_INFO'] variable.
- Footer include allows you to specify anything to be added onto the footer of every proxified page, for example for your Google Analytics tracking code.
- Logging to a text file or multiple text files (date based) can now be enabled from within the script. This is only advisable if you are running with unique URLs enabled - otherwise your server access log will be more useful. You can enable full logging or HTML pages only. Also included is the option to "log until" in case you're just interested in the most popular sites on your proxy and don't want to worry about turning off logging again.

Changes:
- Known errors (i.e. invalid URL, hotlinking protection, access denied by whitelist/blacklist) occuring inside a frame will now return an error with a link back to the index. Unframed errors will follow the normal process of redirecting immediately back to the index.

Notes:
This was mostly tested last night and I've made a few changes that could have screwed everything up. There's also now so many different combinations of options with a big effect on the running of the proxy, (i.e. encode pages on/off, unique URLs on/off, encode URL on/off, path info URLs on/off), that it's very difficult to test everything. In theory there could be some fairly major problems but hopefully it's all good. Upgrade instructions included in INSTALL, as usual.

[EdwardTobia]

Great, im the first to download

Uploading to test now...

Regards,

Edward.

[EdwardTobia]

Hmmmm i think something in this release has broken the youtube mod as its not working for me anymore...

I just get the Javascript turned off error even though i have unticked the remove javascript box...

[hibob]

Youtube mod is broken for me to.

Also, the setup.php does not work to set up the logging destination, it is blank after each time you try to set it up again(it does now write the destination to includes/settings.php)
And yes, I have settings.php chmodded to 777, as the other options change.

[lanmonkey]

fantastic Nick, Ill try this out when I get home tonight.

[Nick]

the setup.php does not work to set up the logging destination, it is blank after each time you try to set it up again

Thanks, fixed and uploaded new package with the change.

YouTube works fine for me with the latest plugin from the youtube topic, with remove scripts on or off.

EDIT: Ah, yeh. If you have pathinfo URLs on then the plugin will need to load the mediaplayer with an absolute URL. Change

data="plugins/mediaplayer.swf" 

to

data="' . optURL . 'plugins/mediaplayer.swf" 

[hibob]

Alright thanks. I'll test it when I get back from work.

Cheers.

[thewird]

I think your missing something with the URL encoding which is important so I decided to register. Since the URL's are going to be so random, it makes it impossible to decode them in case of abuse. Any proxy hosted in the US, although not required by law to log, no host wants to host a proxy where they're response to an information request from the FBI, Homeland Security or even some state police (happens at least once a month for me if not more) is "we have no logs". Also, this makes abuse detection almost impossible. I know I suggested something super encoded which is good but the problem with providing this publicly is nobody has any idea how to admin proxies to be honest and are just in it for the money and don't care what harm they can possibly do.

So I highly recommend you don't release this beta as a release. Some suggestions for the change could be having a separate log file with unencoded logs (time, IP, and URL is all thats needed) FORCED if you you choose this random encoding, or you might want keep the base64 line intact but have it require an extra line with some random stuff, that way you can still search the domlogs for the base64 encoded URL and find what your looking for. I'm sure there's other solutions but you have to keep in mind most PHP proxy owners just upload the script and find a template and don't really care about anything else so whatever it is, it has to be forced onto them.

thewird

[Nick]

The URLs will be uniquely encoded but not encrypted. It may take a little longer to decode but it will still be possible if worst comes to the worst.

The unique URLs option is disabled by default so it shouldn't be a problem. If they then run the setup script to enable them, it advises them to enable the logging system. I'll make it even clearer before the final release just in case.

[thewird]

Yes, its possible to decrypt but the problem arrises when theres 1000+ proxies on the same server all with different encoding mechanisms (if this trend of changing the encoding type continues) which makes it impossible for the admin (not owner of the proxy) search through the logs when complaints arise. I like seeing advancement in the proxy scripts but the developers need to think of the good and the bad at the same time. If you do decide to keep this encoding, I highly suggest the logging be automatically turned on (you can create some sort of system so that it only keeps the logs for 7 days since thats all thats needed to save disk space). This way an admin can do an updatedb and locate the files and copy them to begin log analysis (using grep for example).

thewird