Hi
I have a flash file embedded on a standard page asset which uses xml to load images. When all assets are underconstruction the movie displays fine, but when i make the assets live, the movie does not show.
I think its to do with the xml file but i cannot figure out whats going wrong and why would making something live mean that it wont display on the front end!?
Any thoughts?
When file assets (like images) go Live, their URL changes to include a special _data path if they also have public read permission. This lets the web server serve the file directly, making it much faster.
So what is probably happening is that your URLs are changing.
You have two options: change the XML to use the Live URLs or go to each image and untick the "Allow unrestricted URL" box.
3 options, you can leave all the assets under construction and grant access to public user for write access. If you have lots of files this is the quickest way to deal with them. Could also be classed as a dirty hack by the purists:)
Not just a dirty hack; a security issue. If you don't want everybody to be able to update your images, don't give them write access. Using permissions to get around status and URLs is not the answer here.
The public user would only get read ability when granted write permissions and would not able to access the admin interface or update the images via _admin or _edit, unless that has changed… This used to be a standard workaround for this situation until the "allow unrestricted access" setting was built in and is still useful if you are dealing with a large number of files. There is the option to grant permissions to the public user in read, write and admin. Is it then a security risk that is inherrent or can it be safely used?
If you give users access to edit content that they should not have access to, it is a security risk. The fact that you can't easily exploit it doesn't make it acceptable. If you actually want public users to be able to update the content/metadata etc, then set the appropriate level of permissions using the interfaces provided. But you need to be sure that's what you want.
Also, accessing _edit and _admin is not the only way of updating content with the array of frontend editing tools available. Plus you can't protect against product changes or implementation changes when you've already elevated permissions.
And finally, this is not a "standard" workaround and has never been one. It may be something you (and others) have done in the past, but it is not something that should ever be recommended. Permissions are a serious part of a CMS and should never be set incorrectly to make life easier or get around limitations of the product. That's how you end up in the news…
There are two fine solutions to the problem here. I'm going to stop these security posts now that I've made two posts on behalf of Squiz outlining our concerns with the 3rd approach. People can make up their own minds.
I've had a similar problem when using XML based image listing on flash (a la slideshow pro). Check both the path of the XML file when it's made live and the actual flash SWF file.
Greg, yes, you are totally correct. Granting public write is fraught with danger in circumstances where it could expose the system to compromise, and I would never suggest that Squiz would do this as rule, either now or in the 5 or so years I worked there.
Yes I, and certainly many others, have done this in the past for one simple reason. If you have a flash file that references files relatively and you don't have access to the source for any reason and you want to use it on a site, the ONLY option you have to make it work if your Matrix version doesn't have the option to set "unrestricted access" on files is to employ a method that maintains the url as it exists when in a secure state.
Anyway, I agree with you, enough said.
There is often a 4th option; if your XML is defining the images, you can paste the XML into a Standard Page and refer to the images using the proper ./?a=X links.
You probably still have to set "Allow unrestricted access" to "Yes" for the XML file itself, and change it's web path to have the correct name (and apply a blank design), but it allows the images to be served the Matrix way (which is better performance-wise).
The biggest problem in this circumstance is that Matrix allows you to serve the page with or without a trailing slash. This will completely break serving relative files unless you link them in two places. 