Getting rid of an unwanted URL
I have seen some posts on here close to this topic but nothing that has resolved my issue thus far.
I have a simple flex app that is pretty much a data grid that is populated by a list of xml files that is given by a php file on the server. Using firebug I have tracked the issue down to one location and that is where flash is trying to load the xml url to be parsed into the data grid.
The thing works on our QA but when it is in prod it it has issues. Part of the issue is that the location where the xml files need to be read are not web accessable meaning you can't type a url in a browser to view it, whereas on the qa you can, either way I made the URLs relative but it's still adding a domain to the front of it, example:
flash is fed this url to look for the xml file "../../../placemenxml/some
yet firebug is showing that flash is looking for "http://our.servername.com/placementxml/someFile.xml"
so where is the stupid "http://our.servername.com/" coming from?
I've tried adding <param name="base" value="."/> in the html page and that changes nothing for QA, the QA still has it's servername appended to the front as well.
fire bug says this as a response: "The requested URL /placementxml/someFile.xml
I have a simple flex app that is pretty much a data grid that is populated by a list of xml files that is given by a php file on the server. Using firebug I have tracked the issue down to one location and that is where flash is trying to load the xml url to be parsed into the data grid.
The thing works on our QA but when it is in prod it it has issues. Part of the issue is that the location where the xml files need to be read are not web accessable meaning you can't type a url in a browser to view it, whereas on the qa you can, either way I made the URLs relative but it's still adding a domain to the front of it, example:
flash is fed this url to look for the xml file "../../../placemenxml/some
yet firebug is showing that flash is looking for "http://our.servername.com/placementxml/someFile.xml"
so where is the stupid "http://our.servername.com/" coming from?
I've tried adding <param name="base" value="."/> in the html page and that changes nothing for QA, the QA still has it's servername appended to the front as well.
fire bug says this as a response: "The requested URL /placementxml/someFile.xml
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If the xml is not web-accessible, you can't access it from a web-deployed swf. It's a security feature. I'm guessing your QA compiles the code for a local sandbox (local-with-filesystem) so that it can access the local filesystem. That cannot work when it is deployed to the web.
If you want to embed xml files into your application, it turns out you can. http://dispatchevent.org/roger/embed-almost-anything-in-your-swf/
In the comments of that post, they seem to suggest that you need to specify a mime-type of octet stream, rather than text/xml, like this:
[Embed(source="someFile.xm
private const myXML:Class;
var x:XML = XML(new myXML());
trace(x.toXMLString());
If you want to embed xml files into your application, it turns out you can. http://dispatchevent.org/roger/embed-almost-anything-in-your-swf/
In the comments of that post, they seem to suggest that you need to specify a mime-type of octet stream, rather than text/xml, like this:
[Embed(source="someFile.xm
private const myXML:Class;
var x:XML = XML(new myXML());
trace(x.toXMLString());
ASKER
If the xml is not web-accessible, you can't access it from a web-deployed swf.
I had a feeling that might be the case, seems as if I might need to find a work around.
I can't embed the xml files since they are generated by another swf (they are exam results)
I'm thinking I might have to have php read the xml and send the data back to flash, stupid but seems like the only way right now.
I wouldn't flat-out call the security features stupid, but they certainly can be frustrating. Just remember there's nothing more frustrating than someone exploiting a vulnerability in your app to destroy or steal important data :)
I think it makes a lot more sense to expose xml files using a service, rather than putting them in a web-accessible directory, so yeah, I think you should go with that. For one thing, assuming that users may have expectations of confidentiality concerning exam results, you would be able to add some kind of password protection to the php service you use to expose those xml files.
I think it makes a lot more sense to expose xml files using a service, rather than putting them in a web-accessible directory, so yeah, I think you should go with that. For one thing, assuming that users may have expectations of confidentiality concerning exam results, you would be able to add some kind of password protection to the php service you use to expose those xml files.
ASKER