Fair enough and thanks for the clarifications. I'll say I didn't think to suggest the Flash debugger as I wouldn't have thought that to be easier to setup (for one not familiar with it) than a proxy tool. :-) Glad you did think to use it and resolved things.
Then again, when you say you had "issues" with getting a proxy tool setup due to "convoluted configuration", I'll say it may some day be worth getting that resolved, as such client proxy tools can be so valuable in debugging any client/server communications (whether Flex, Flash, Ajax, etc.) If the challenge was with any one tool, I'll repeat the link to my list of dozens of alternatives (http://www.cf411.com/#proxy). I realize you may well have tried others. Again, I point this out as much to motivate others facing a similar challenge in the future. :-) /charlie From: [email protected] [mailto:[email protected]] On Behalf Of Dawn Hoagland Sent: Saturday, March 27, 2010 4:17 PM To: [email protected] Subject: Re: [ACFUG Discuss] Flex, Flash Security and crossdomain.xml Thanks Charlie - checking to ensure the crossdomain.xml file was being loaded was our first order of business. We confirmed with the IIS logs that it was being loaded and did some preliminary testing by loading the website using the server's IP address rather than domain name. Since the requesting url (IP address) didn't match flex's remote object call (fully qualified domain), it wouldn't work w/o the proper crossdomain.xml file. We had a few issues getting a client proxy tool setup, but I think that had more to do with our convoluted configuration than anything. Finally, I researched and found how to turn debugging on for the Flashplayer to see if we could find out a bit more of what was going on from the client side. It was the error messages there that made us realize the issue where the SWF was compiled with the Remote location that was not being resolved externally. So while the crossdomain.xml was an issue, it wasn't the entire issue. It also brings to mind some interesting possible issues for future deployments due to how applications are deployed in our specific environment. Thanks again to all for getting us pointed in the right direction. Dawn On Sat, Mar 27, 2010 at 3:49 PM, Charlie Arehart <[email protected]> wrote: Dawn, I can't tell if you (or others) saw my original note in reply to your question, offered Thursday when you sent the note. My first point was, "You should confirm first that that file is indeed being requested on the server." I also indicated how to check that, and made the similar suggestion to Doug that a client proxy tool could have helped if it wasn't obvious just from your attempting a browser request for the file (which was another suggestion I'd made). I'm just saying all this as much to make sure that others realize that this challenge with the crossdomain.xml files isn't quite that unique. It's not what most tend to think of first, but it's always worth ruling out first. :-) /charlie ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
