Symphony.

no image appears and the net tab in Firebug records the server response as 500. Any ideas?

Try loading that image URL directly in the browser. Do you see a more specific error message? If you just see white, try enabling PHP error messages. An easy way to do so is to add this right at the top of your .htaccess file:

  php_flag display_errors on

@czheng write modes in the config are 775 for both files and directories. @nickdunn That’s the weird thing, I can view the image directly no problem.

As czheng says I feel it must be an apache thing. But why does it work on all the existing images? are they all cached? if so where? Does JIT use imagemagic or GD2? The server has GD2 installed, but again if it didn’t work for all images I would be more inclined to think that was the issue. The image directory has permissions 775 with all files belonging to the account holder and in group apache (it’s CentOS so PHP belongs to group apache). I admit to being deeply puzzled by this.

Images should be cached under /manifest/cache/. Sounds like a GD Library problem. Perhaps you can pastie up your phpinfo().

Link to Pastie: http://pastie.org/695637

Can’t see a cache in manifest

If there isn’t a cache folder in manifest, create one and set its permissions accordingly and try again. This could be your only issue.

Also, I’ve also noticed something strange. Based on the phpinfo() provided, PHP was installed with the --without-gd. I’m not sure why this flag was explicitly set.

The image tag renders fine, but no image appears and the net tab in Firebug records the server response as 500. Any ideas?

I have same problem with jpg images. After a lot of of test with different images dimensions and different naming conventions, I found that the 500 Internal Server errors have a content-type: text/html for the images if the width is from 1188px up and it is image/jpeg when images width is from 1187px down.

It seem strange for me, I can’t figure out why. Some ideas?

EDIT Another strange behaviour: the image with a width less than 1187px is visible if I use MODE: 1 or 2 but it returns a 500 Internal Error if I use Mode: 3

Same problem occur when the image height is more than 1188px :-|

Have you tried increasing the memory limit on your site? Sounds like the script runs out when it tries to process images over a specific size perhaps.

If you manually change the memory limit, do larger images work? At the very top of your .htaccess:

php_value memory_limit 128M

(Sets to 128MB).

@nickdunn: thank you very much. I was looking around this for a while. My knowledge of what it can be done with htaccess is not so high

That will remove the ability for Symphony to pull external images, albeit superficially. We will look at ways to address any security concerns for Rev 6.

I know this was way back, but I haven’t really seen any news here..

What I would suggest is to create a hash generator that creates a hash based on (for instance) filename, filesize, size to resize to and a random key (set on install). Then, jit should only return an image if this key is correctly set in the url. (for instance: http://ww.host.com/image/key/mode/ etc)

This key could be very easy to provide using an xslt utility which uses a param set by the jit extension, and the params I described above.

I’m not really good with generating hashes, especially from xslt (so I won’t be able to make the xslt utility). But to me it does sound like a very good solution.

Let me know what you think!

I think this problem has been solved with the image resizer’s replacement Just In Time (JIT) Image Manipulation which provides a whitelist in System > Preferences so that you can specify the domains from which external images can be served.

I think this problem has been solved with the image resizer’s replacement Just In Time (JIT) Image Manipulation which provides a whitelist

Yes, but whitelisting domains does not stop JIT from loading huge images from those domains and resizing them to 1600x1200, 1601x1201 etc by a malicious script..

I mean, I just did a test on localhost and totally hung my pc (2gb ram) with a script written in cli php.. (I only allowed localhost images to be resized, but still).

Just did another test, resizing an image from 400x400 to 4300x400 caused my cpu to top 60% for about 10 seconds (didn’t time it or anything).

Opening that thing in two tabs with different sizes put my cpu to 100% for about 20 seconds (max execution time of php).

If this were a shared hosting account, my guess is the hoster would be sending angry mails by now. This is not something I want everyone to be able to do!

I’m using a resizer build by one of our clients at the moment and they get around this by using named configurations for each size. If you want a 150x300 image, you specify your settings in a config file (either in XML, JSON, YAML etc), give it a name, perhaps “homepage-thumbnail” and call the resizer like:

/resizer/homepage-thumbnail/path-to-image.jpg

This is similar to your idea, but requires slightly more configuration. However I like the fact that the size settings are stored in a single place so can be changed globally.

Perhaps the JIT extension could provide an interface for building these configurations? Either a complete UI for selecting each size/type, or as simple as a textarea for pasting the mapping of “name” to “url” i.e.

homepage-thumbnail: /2/150/300/5/
homepage-large: /2/500/500/5/

If a matching name is detected in the URL, the name is swapped “internally” with the config values that JIT expects.

However the hash idea is a good one. Unfortunately hashes are rather tricky to generate using XSLT. I have found a base64 encoder in XSLT 1.0 (which also needs this) which could work, particularly when salted with a unique key provided in the param pool by the JIT extension.

There was talk about enabling PHP functions form within XSLT, which would allow us to use the md5() function in XSLT directly. That would save a lot of XSLT headaches.

However we need to be wary of changing the JIT extension since it’s a core bundle, and used by almost every user. Therefore it needs to be upgradable, and the barrier to entry kept as low as possible.

Tricky.

However we need to be wary of changing the JIT extension since it’s a core bundle, and used by almost every user. Therefore it needs to be upgradable, and the barrier to entry kept as low as possible.

Ofcourse, the additional security could just be a setting in the settings panel. Then updating would not change anything unless you want to..

However the hash idea is a good one. Unfortunately hashes are rather tricky to generate using XSLT. I have found a base64 encoder in XSLT 1.0 (which also needs this) which could work, particularly when salted with a unique key provided in the param pool by the JIT extension.

That’s what I was afraid of. If in the future using php is possible that would be perfect for this use.

I’m not really a big fan of using php inside xslt templates though, as I think that might turn the standard symphony into a joomla-like mess..

I will do some more thinking about this, I’ll keep you posted!

I’ve forked JIT and added the ability to create named “recipes”. A recipe comprises a name, and a list of JIT parameters in an XML file.

http://github.com/nickdunn/jit_image_manipulation/commit/91a8cd8f69eb67b24283cf7ee19a432f3498e2cd

<?xml version="1.0" encoding="utf-8"?>
<recipes enforce="no">
    <!--
        Possible recipe parameters:
        - <width>
        - <height>
        - <position> (crop)
        - <background> (colour)
        - <external> (0 or 1)   
    -->
    <recipe name="blog-post" mode="2">
        <width>600</width>
        <height>500</height>
        <position>5</position>
    </recipe>   
    <recipe name="flickr-thumbnail" mode="2">
        <width>75</width>
        <height>75</height>
        <position>5</position>
        <external>1</external>
    </recipe>
</recipes>

This then allows you to call a URL such as:

/image/4/blog-post/uploads/myimage.jpg

Or:

/image/4/flickr-thumbnail/farm3.static.flickr.com/2663/4143072903_3a3daa14d4_m.jpg

The benefit of this approach is that people cannot change the sizes in the URL parameters and potentially flood JIT with requests creating numerous sizes of the same asset.

By changing the enforce attribute to yes you disable all other modes (i.e. /image/{mode}/...), such that they return 404 errors and only named recipes return an image.

It’s therefore backwards compatible, but gives you the option of locking-down should you desire.

What do you think about this approach?

I think this is a really great improvement especially considering this issue:

The benefit of this approach is that people cannot change the sizes in the URL parameters and potentially flood JIT with requests creating numerous sizes of the same asset.

Nevertheless this might be handled more finegrained:

By changing the enforce attribute to yes you disable all other modes (i.e. /image/{mode}/…), such that they return 404 errors and only named recipes return an image.

I sometimes like to resize an image using JavaScript. Therefore being able to use both — recipy and the normal size modes — would be great. I like the security approach of your additions: Would it be possible to forbid size modes on a per section base? Or add some kind of authentification token to enable modes?

What do you think about this approach?

I love it.

Nice one, nick. But how do I create these recipes? Just editing the XML file or there will be an interface for that?

Just editing the XML file

Yep. I don’t see a need for an interface really: normally you’d be writing your URLs into your XSLT, so one can guarantee it is a developer doing the task. But really it’s just a proof of concept — an idea — which will hopefully encourage the core team to think this through. Perhaps this would be the default way of doing things in Symphony 3?