I have a flex app running on my server.
I have had a request from some clients to have the swf loaded on their server, so that their customers dont have to be transferred to my server to login; i.e. from the user's point of view it looks like they are logging in from theirsite.com instead of mysite.com
I tried something really simple, and that was to give them a html wrapper to host on their site. The only modification that I made was to change the "src" var to:
"src", "https://www.mysite.com/app/myapp.swf"
and
embed src="https://www.mysite.com/app/myapp.swf"
To my surprise, this worked perfectly. And best of all, the service calls still seem to come from mysite.com, so I dont have to bother with modifying the crossdomain.xml file.
All good it seems.
Are there any issues or downsides to the above that I should be aware of?
If you're doing an ExternalInterface calls to JavaScript in the enclosing page, this may cause a security error; since the SWF from your domain shouldn't be able to access HTML content served from your client's domain.
I expect that is a fringe case though. Aside from that, what you're doing is not much different than what YouTube does. I've done the same thing with The Flex Show player. I don't think you'll have any issues. And I do not believe that this approach makes your app any less (or less) secure.
Related
I made a blog widget in flex. I need manipulate cookie in my widget which is added to my user's blog. But under some circumstance, some blog hosts forbid accessing to javascript, so i can not access cookie in flex by externalInterface. Does anyone know how to access cookie in this context? thanks.
You need to set allowScriptAccess to "*" in your embed code. Unfortunately, you cannot allow access on a per domain basis, so it's all or nothing. However, the owner of the blog might not want to grant this privilege, in which case you just cannot count on having access to Javascript from your swf.
PS: If you are allowed to serve a swf from the same domain with granted access to Javascript, you might be able to use it as proxy for sending the data retrieved with javascript to the swf served from the other domain. Not sure if this is the best idea, though.
My answer is, you can't access browser cookies from the Flash Player. The ExternalInterface usage is kind of a hack.
Based on the error, it sounds like your SWF is being served from a different domain than the web page that contains it. Is that true? If so, that is the cause of the error. Isn't that the same sort of approach that "Cross Site Scripting" exploits use?
You can allow JavaScript to access it's HTML wrapper from a different domain by specifying the allowScriptAccess to always in the SWF embed code. More info in the Adobe docs.
You can try adding a crossdomain.xml file to the main site, although I did not think that would have an effect because I'm pretty sure that ExternalInterface usage is not a crossdomain.xml checking case.
I'm curious as to where the cookie is coming from. If your Flex application is creating the cookie via a SharedObject then you don't need javascript to access it. If the cookie is coming from another application/source then to my knowledge, the only real way to access it is via the javascript externalinterface method.
I have a widget that is added to random websites. The widget needs to fill an iframe with content. I need the iframe source to be from the same domain as the website it is embedded in.
To do this I want to ask the site owners to put a file in their root folder that will be used as a proxy to my server.
My question is -how can I implement such proxy with static html/js/? file without using a server side scripting?
I'm not really clear how such a proxy would work/help either way. Are you looking for something like <base />?
The only issue with the base element is that it can't be turned off once it's turned on. If the iframe is the last thing on the page, or at least the last thing with either src or href, you could set it just above. But I'm not sure that this will allow js to access the iframe as though it were by proxy.
And again, I'm still not sure how a file on the remote server will make the iframe seem like it's on your domain. And I have serious doubts whether the site owners will extend such a favor, since doing so would allow hackers to use your site as a backdoor into their server.
I'm not sure how browsers/js policy is in terms of redirects and rewrites, but maybe you could go with something like pointing the iframe to your own server, and having that page actually go to their page, either by mod_rewrite or a redirect. Either way would be server side, so maybe that's not an option. I have heard tale of another thing that works, but have yet to see it in action... You have the site owners add a script with:
document.domain = "yourserver.net";
And be sure to set it on your script as well. This makes them play nice, supposedly. But they may not go for that if it breaks their site for other things, unless there is someway their page can tell it's inside of an iframe and can set that property conditionally.
Good luck
I've recently started embedding JavaScript and CSS files into our common library DLLs to make deployment and versioning a lot simpler. I was just wondering if there is any reason one might want to do the same thing with a web application, or if it's always best to just leave them as regular files in the web application, and only use embedded resources for shared components?
Would there be any advantage to embedding them?
I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.
I doubting and questioning the validity of Easement's comment about how browsers download JavaScript files. I'm pretty sure that the embedded JavaScript/CSS files are recreated temporarily by ASP.NET before the page is sent to the browser in order for the browser to be able to download and use them. I'm curious about this and I'm going to run my own tests. I'll let you know how it goes....
-Frinny
Of course if anyone who knew what they were doing could use the assembly Reflector and extract the JS or CSS. But that would be a heck of a lot more work than just using something like FireBug to get at this information. A regular end user is unlikely to have the desire to go to all of this trouble just to mess with the resources. Anyone who's interested in this type of thing is likely to be a malicious user, not the end user. You have probably got a lot of other problems with regards to security if a user is able to use a tool like the assembly reflector on your DLL because by that point your server's already been compromised. Security was not the factor in my decision for embedding the resources.
The point was to keep users from doing something silly with these resources, like delete them thinking they aren't needed or otherwise tamper with them.
It's also a lot easier to package the application for deployment purposes because there are less files involved.
It's true that the DLL (class library) used by the pages is bigger, but this does not make the pages any bigger. ASP.NET generates the content that needs to be sent down to the client (the browser). There is no more content being sent to the client than what is needed for the page to work. I do not see how the class library helping to serve these pages will have any effect on the size of data being sent between the client and server.
However, Rjlopes has a point, it might be true that the browser is not able to cache embedded JavaScript/CSS resources. I'll have to check it out but I suspect that Rjlopes is correct: the JavaScript/CSS files will have to be downloaded each time a full-page postback is made to the server. If this proves to be true, this performance hit should be a factor in your decision.
I still haven't been able to test the performance differences between using embedded resources, resex, and single files because I've been busy with my on endeavors. Hopefully I'll get to it later today because I am very curious about this and the browser caching point Rjlopes has raised.
Reason for embedding: Browsers don't download JavaScript files in parallel. You have a locking condition until the file is downloaded.
Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.
Regarding the browser cache, as far as I've noticed, response on WebRecource.axd says "304 not modified". So, I guess, they've been taken from cache.
I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.
Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.
You know that if somebody wants to tamper your JS or CSS they just have to open the assembly with Reflector, go to the Resources and edit what they want (probably takes a lot more work if the assemblies are signed).
If you embed the js and css on the page you make the page bigger (more KB to download on each request) and the browser can't cache the JS and CSS for next requests. The good news is that you have fewer requests (at least 2 if you are like me and combine multiple js and css and one), plus javascripts have the problem of beeing downloaded serially.
I am developing a flex charting web application which gets data from csv files. This application is supposed to be installed on the website of a client. The client uses a web server management system where the URLs generated are pretty long and contain non-alphanumeric characters. An example is given below:
http://www.example.com/EXTERNAL/ORGANIZATION/0,,contentMDK:20135608~pagePK:64060242~piPK:64060289~theSitePK:299948,00.html
The problem is that on my test server, the application is running just fine. But when deployed on the client's site, the application and the charts load, but the CSV data fails to load. The error given is:
Input output error: IO_ERROR
I have tried both relative referencing (relative with respect to the swf file) and absolute reference to the URL of the csv file. But both approaches have failed.
Any ideas?
I would ideally like to stay away from absolute URLs since that would break down if the charts need to move to another location.
Thanks
Vinayak
Umm, I don't know what to say really. Not knowing much about the server I'll have to resort to a list of things I can think of. Some of these are admittedly just a stab in the dark. In general it appears that this is a server side issue and as a front end developer you can't be expected to solve this. I know that getting the application to work is the priority here, but if you don't have access to the server there not much you can do to this issue.
First let's eliminate the completely obvious. Is the file ending definitely supposed to be .html and not .csv?
My original thought was that the CMS is somehow blocking Flash from loading the content, but would allow a browser to access it. Since it won't allow that either there are three options that come to mind:
1) The server or the browser does something to the URL when you make the request. Try installing the LiveHTTPHeaders (link) add on for Firefox, that'll allow you to look at the raw HTTP requests and responses. There might be some server side redirects that affect the request. The HTTP Headers should help you with that too.
2) The .csv files are kept in a folder that the web server doesn't have read access to.
3) maybe you need to use HTTPS instead of HTTP. This would be a bit strange since you are getting the URL from the server in the first place. The clients server admin should be able to sort this out for you.
4) I'm not sure what would happen if the script that handles your request is Python. In Python the colons are directory separators, so that might throw the whole thing off.
5) The clients management system does something strange to the URL before it's handed to you. Although I'm not sure how you would test this.
That's it I think. I'm out of ideas for now. For the testing I would forget the flex application and just try the requests from the browser address bar first. Since the application is working on your test server the issue shouldn't be your code. When you get the requests to work on the browser, if they still don't work from Flex then it's your code.
I don't know how much it helps, but there is an as3 CSVLib available.
About the IOError, can you please paste the text ?
If you listen for the IOErrorEvent and trace event.text in the handler,
you should something similar to this:
Error #2035: URL Not Found. URL: yourFile.csv
HTH,
George
Back in the days before Visual Studio Web Server we would host our local dev inside IIS. If you have a workstation version of IIS that means only 1 website. What if you are working on several websites. Easy: create them in VDIRs, e.g. http://localhost/ProjectA, http://localhost/ProjectB.
Living in a VDIR doesn't sound so hard. Make sure all your images/CSS/links are relative paths, use the "~" a lot. Sounds like a good practise. Hardcoding images etc so they only work when the application is served from "/" sounds like a bad practise.
There are some nuances anywhere you have to build a link (mostly not common scenarios):
eg; PROD: http://prodserver.com/images/up.jpg -> DEV: http://localhost/ProjectA/images/up.jpg
links / images in emails
flash/javascript/silverlight requests data from the server which contains links to images
The full link to the a PayPal IPN (the page paypal POSTs their response too)
So.. Are you doing this? Advantages / disadvantages? Any other gotchas I've missed?
I always avoid hardcoded paths, URLs, etc. unless there's a specific reason to do otherwise. Things inevitably change, and there's always the jump from your dev site to production.
The part that is usually the biggest nuisance would be in reusable client behaviors that need to reference other paths, and themselves can be reused in pages across the application's directory structure.
I like the idea handler that responds to "globalvars.ashx" (or something like that; there are many ways to handle this) which dynamically emits (and allows caching) properties regarding the global application properties.
Say the handler responsible for globalvars.ashx writes the result of something like this:
String.Format("var ApplicationProperties = {{ RootPath:{0} }};", Request.ApplicationPath);
Your JS behaviors could theoretically reference that property object at any point via ApplicationProperties.RootPath.
In short, yes. The disadvantages of not doing so outweigh the benefits. I actually think your first two points can also be mostly mitigated from using app-relative paths ("~"), but nevertheless, some scenarios such as "integration-level" ones (like PayPal) may indeed prove tricky.
But at the end of the day, if you need to host your app in a virtual directory you are virtually guaranteed problems if you haven't coded your app to be vdir-friendly from the get go. I know I have.
Some background/context: My current production environment at work is almost always a virtual directory anyway, so I do this by necessity. And I've never had a problem when an application was created as a root-level website. This certainly wouldn't be the case if it was the other way around.