Thomas Wright

Hello,
I am afraid neither of these would be possible as the behaviour is defined by WordPress rather than my plugin.

Just to let you know,
In the latest version this work around has been removed so it should now work correctly.

@susanne and @bonusball
I should be able to add both of these features soon.

Hello,
Yes, it should be possible. I will just need to modify the plugin to allow you to specify the folder in which files are uploaded and then I will post instructions on how you can include this in your blog.

Hello and thank you for your suggestions,

firstly I should be able to add this upload resize functionality in the next version.

Secondly the problems with Atahualpa have been posted on their forum with no response – the upload form depends on functionality which varies from theme to theme (specifically how they implement the comment form hook) although I might be able to find a better work around in the future.

@waffles007
sorry for the slow reply,
I have just made quite a few improvements to the plugin and now this change should be relatively easy although I might go for some kind of tags system instead. Anyway I will see if I have time to add this feature.

Hello,
I have just finished a new version of the plugin (0.50) which should completely resolve this issue.

Hi,
I’m afraid you seem to have gotten bitten by a server configuration issue, it looks like the plugin was unable write to its configuration files due to a limitation imposed by your webhost. Hopefully I should be able to make it more failsafe in the future but if anyone else experiences similar issues, you can simply delete the plugin’s folder to disable it. I am sorry for any frustration this has caused.

Yes, I will look into to adding an auto-resize script but it seems to me that the best way to do this is as a cron job on the server as it would be faster, allow processing during non-peak times, not add a wait on image upload and just be generally more manageable.

In your second point you have stumbled across possibly the single biggest annoyance I faced whilst writing the plugin ?? Seeing as the only hook I could use is A: very theme dependant (around 20% seem to get it wrong) and B: already inside a form (and html does not support nested forms) the code to handle it has to be a bit hacky and is not ideally placed – hopefully soon I should be able to replace this with some nice javascript and all should be well…

In the newest version of the plugin (0.30), I have added support for restricting to uploads to certain users and images only.

Uploads for certain pages only should be coming soon (I hope…).

I have completely rewrote this bit of the plugin in the 0.30 release based on a regular expression checking filenames so now it should be a lot more secure – the issue you were hacked via now should no longer be possible (I now have a folder full of suspiciously named files and am testing each release).

I have also added options to restrict which users can attach images in the options page. You could also set up your webserver to disable script execution in that folder as an additional level of protection. There is also now an whitelist based “images only” option – this will cut down a lot of the “unknown” factor (I cannot blacklist every single executable filetype for every server out there).

As always the plugin’s code is open source so anyone concerned can check it themselves:

// Check upload against blacklist and return safe unless it matches
	function filetype_blacklisted () {
		return preg_match ("/(\\.(.?html\\d?|php\\d?|f?cgi|htaccess|p(er)?l|py(thon)?|exe|bat|aspx?|sh|js)|^\\.|~$)/i", $_FILES['file']['name']);
	}

Anyway, good luck and I hope you enjoy future releases of the plugin.

Hi,
I will definitely look into this when I get round to adding an options page to the plugin ?? . Thank you for the suggestion and if you have any more please let me know.

Ah, if you mean via a rel in the tag for inclusion that is completely filtered. The actual links which appear on the page are simplified to bbcode style [img][/img] and [file][/file] which is then translated into html via a wordpress filter at the time of page generation. Hopefully that prevents the possibility of XSS (the only user input which gets into the main wordpress page is the bbcode link to the uploaded file). I have also been thinking it could generate a custom .htaccess for the upload directory which turns off cgi and php execution to protect against zero day flaws.

If anyone thinks that there might be more problems please let me know and I will look into it ASAP.

Hi,
thank you for the advice – I will review how the files are checked when I have time. I thought that as most servers determine whether files are executed by filetype, if someone uploads a .php renamed to .gif, it will be named .gif on the server anyway so cannot be executed? I have seen a lot of people saying that mimetypes can be spoofed and vary between browsers whereas there are only a fixed no. of filetypes that a server will run a scripts. I have tried googling but everyone seems to disagree on this. I might just blacklist both just to be safe ??

Hi,
I maintain the plugin and in the new version I have added a new blacklist of disallowed filetypes which prevents users uploading commom dangerous file types which should reduce the risk but with any upload mechanism there is always potential for exploitation. In future versions I will add the option of a whitelist which only allows certain file types. I am trying to do everything possible to prevent it from being exploitable but if users are allowed to upload files on any site this will increase the exposure to hacking. With uploads you should also consider security on the server side – mechanisms such as suPHP, running the webserver under a chroot and of course keeping regular, offsite backups are always a good idea. It probably also is not a good idea to run beta plugins on a production site ?? .
$blacklist = array(".php", ".phtml", ".php3", ".php4", ".php5", ".php6", ".cgi", ".fcgi", ".htaccess", ".js", ".shtml", ".pl", ".py", ".exe", ".bat", ".sh");

Hopefully the new version is much more secure – if anyone knows any other filetypes which should be blacklisted please tell me.