I had a discussion with my colleague about Flash security. We're in the phase of planning some things for our web project that is using Flash plugin to display content. We need to dynamically pull settings for the Flash application from the server, using JSON.
Proposal that I offered was that we should save an extra HTTP request to pull the data file after the plugin is loaded and embed the JSON directly in the page containing the Flash plugin. Flash would fire a Javascript function that'd return the deserialized JSON data to it.
My colleague opposed this proposal with significant "security concerns".
I believe that there's literally zero difference between these two approaches besides the fact that his approach requires additional HTTP request. All of this is client/server and client should never be trusted. If I want to change the data that is in the JSON query, I can do that in both cases. File pull is little more difficult to hack though, but possible with custom HTTP proxy.
What are your thoughts?
There is no difference. Both can be fabricated.
if you really care that much about delivering original settings to the .swf:
don't use http - httpFox is a brilliant plugin - use a server that supports RTMP/RTMPE and NetConnection.call() to retrieve the data.
create an algorithm for validating original json so that your app won't work if the config doesn't pass the test.
after the config is loaded your swf might check the values with the server (not all at a time) and throw an error if something goes wrong
Related
I taught myself programming so my knowledge is very fragmented and now I have encountered a fragment I know nothing about. Sending and receiving Date. In addition I want to do it across domains. I know about the security policies that prohibit this but have read about some solutions. I still can't make sense of it in relation to my challenge.
What I want to do:
I want to build a plugin that sends data to my server when a function is called. The function is bound to an event listener.
this plugin contains of a little html-form and some js in the back. i want to send json or simular.
my questions:
I) how do I send data to an other server?
II) how do I receive this data? I know about parsing and dom but all I did so far is handle requested data. now this data is posted to my server-app without me knowing beforehand. the data is used to update a DB. the backend is coded in JS or python. I would prefer JS for compatability reasons.
III) how can I test the cross server connection on my local machine? especially without an active internet-connection?
I don't expect a complete guide or the code i need. just the resources and where to get the knowledge-chunks I need to build this.
Thanks a bunch in advance!
I) how do i send data to an other server?
You may use AJAX (or jQuery.ajax a more convenient way)
II) how do i receive this data? i know about parsing and dom but all i
did so far is handel requested data. now this data is posted to my
server-app without me knowing beforehand. the data is used to update a
DB. the backend is coded in JS or python. i would prefer JS for
compatability reasons.
As long as you send some data via AJAX, the browser makes a HTTP call and you could receive the data from server-side. Both JS or python would compatible with your client-side javascript and seldom do there have compatibility issue.
III) how can i test the cross server connection on my local maschine?
especially without an active internet-connection?
localhost and 127.0.0.1 is treated as different host and I usually use these to test cross server scenario. One issue of AJAX is that browser usually disallow Cross Domain calls unless you specify Access-Control-Allow-Origin headers.
I have a series of .swf files that I inherited from an old version of a site I'm trying to rebuild.
When flash_element.submitForm() is called, they POST some data directly to a static url ("/submit"), then depending on the response, reload the browser page.
I would very much like to capture the data that they POST using javascript - preferably without it getting sent at all - so that I can have more intelligent logic to handle to request/response than is built into the .swf files I've inherited.
Basically: When a flash object makes a http request, can I catch and cancel this event in Javascript?
Basically no. You can try and use the various swf disassembler/reassembler things like the swfdump.exe that comes with flex to get rid of the post, or change it to a javascript call. There's precious little control or knowledge you can gain from a swf directly from javascript that the swf doesn't make explicitly available via the appropriate API's. This is is as it should be- if what you suggested were possible it would be a fairly serious security hole.
Using Google Mini for a website that needs output from the Google Mini in a JSON/JSONP format for front-end querying purposes. Google Mini does publish an XML feed that could potentially be used by a middle process to convert to JSON/JSONP.
Can Google Search Appliance / Mini output to JSON/JSONP using a plug-in, modification to an XSLT template, or other unknown method?
Solutions discovered
Seems like digging through code.google.com reveals that GSA/Mini does not have a method to output in the JSON/JSONP format without using XSLT to create the feed. It is a matter of creating this XSLT to do the conversion.
Other option is to create a server-side script using available technology (PHP?) to retrieve the XML from GSA/Mini and convert the feed to JSONP upon request from the Front-end (AJAX). Downside is the increased overhead in this call.
Update 10/8/2010
Created a Google Mini frontend that generates a JSONP response.
I had the same problem trying to get JSON and JSONP. The solution worked in general on all other browsers, but IE. I could not change the mime-type to something other than text/html since that was global in GSA. Created an XSLT to solve that problem for browsers like IE which will not allow content to be returned due to a security feature ( IE – SEC7112 )
https://github.com/kjonnala/gsa_template
Hope that helps.
I'm working on approach #2 above. We have version 6.4 of the appliance and it provides JSON for the suggestion service (probably new since Riley's question). For example:
http://code.google.com/apis/searchappliance/documentation/64/xml_reference.html#RichOutputFormat
What I ran into was that cross-domain limitations prevented using the appliance JSON service on non-appliance website search forms, including those in subdomains of our shared high level domain.
I'm testing a simple Java servlet now that makes the suggest call. It takes incoming requests, gets the response from the appliance, outputs in JSONP and sends back to the calling page.
There are a couple references I've found related to proxying the suggest service:
http://groups.google.com/group/Google-Search-Appliance-Help/browse_thread/thread/72406a271a6d9917/
http://www.mcplusa.com/blog/2009/07/adding-google-search-appliance-suggest-search-to-your-existing-page/
http://sites.google.com/site/lightbends/gsa_qs_6_2
and some related to JSONP with jQuery:
http://devlog.info/2010/03/10/cross-domain-ajax/
http://www.ibm.com/developerworks/library/wa-aj-jsonp1/
JSON to JSONP in the servlet is quick and probably dirty in the approach I'm taking :)
It's not in production yet, so I can't speak to what we'll find in terms of performance and other challenges. I like that the service is exposed from a secondary server rather than directly from the appliance (allowing for throttling of incoming requests if needed, etc.) if the performance can keep up.
October 1, 2010 Update
Sorry - my post above applies only to the suggest service and not to the general search results. You could still take the XML response, process and wrap that in JSON/JSONP, but that would take longer I suspect. I was using the JSONP in the context of suggesting search queries with jQuery autocomplete, so having the quick response (as they type) is important.
I am creating a Web Application using JSP, Struts, EJB and Servlets. The Application is a combined CRM and Accounting Package so the Database size is very huge. So, in order to make Execution faster, I want prevent round trips to the Database.
For that purpose, what I want to do is create some temporary XML files on the client Machine and use them whenever required. How can I do this, as Javascript do not permits me to do so. Is there any way of doing this? Or, is there any other solution which I can adopt in order to make my application Faster?
You do not have unfettered access to the client file system to create a temporary file on the client. The browser sandbox prevents this for very good reasons.
What you can do, perhaps, is make some creative use of caching in the browser. jQuery's data method is an example of this. TIBCO General Interface makes extensive use of a browser cache for XML data. Their code is open source and you could take a look to see how they've implemented their browser cache.
If the database is large and you are attempting to store large files, the browser is likely not going to be a great place for that data. If, however, the information you want to store is fairly small, using an in-browser cache may accomplish what you'd like.
You should be caching on the web server.
As you've no doubt realised by now, there is a very limited set of things you can do on the client machine from a web app (eg, write cookie).
You can make your application use the browser plugin Google Gears, that allows you a real clientside storage.
Apart from that, remember, there is a huge overhead for every single request, if needed you can easily stack a few 100 kB in one response, but far away users might only be able to execute a few requests per second. Try to keep the number of requests down, even if it means adding overhead in form of more data.
#justkt Actually, there is no good reason to not allow a web application to store data. Indeed HTML5 specifications include a database similar to the one offered by Google Gears, browser support is just a bit too sporadic for relying on that feature.
If you absolutely want to cache it on the client, you can create the file on your server and make your web app retrieve it. This way the browser will fetch it and keep it on the client cache.
But keep in mind that this could be a pain for the client if the file is large enough.
I'm building an ASP.NET AJAX application that uses JavaScript to call web services to get its data, and also uses Silverlights Isolated Storage to cache the data on the client machine. Ultimately once the data is downloaded it is passed to JavaScript which displays in on the page using the HTML DOM.
What I'm trying to figure out is, does it make sense for me to make these Web Service calls in Silverlight then pass the data to JavaScript once it's loaded? Also, Silverlight will be saving the data to disk using Isolated Storage whether I call the Web Services with JavaScript or Silverlight. If I call the Web Services with JavaScript, the data will be passed to Silverlight to cache.
I've done some prototyping both ways, and I'm finding the performance to pretty much be the same either way. Also, one of the kickers that is pointing me towards using Silverlight for the whole client-side data access layer, is I need to have timers periodically check for updated data and download it to the cache so the JavaScript can loading when it needs to.
Has anyone done anything similar to this? If so, what are your experiences relating to performance with either the JavaScript or Silverlight method described?
Since Silverlight can handle JSON and XML based services, the format of the response is totally irrelevant. What you must consider, however, is the following:
1) Silverlight is approximately 1000 times faster than JavaScript
2) If your web service is natively SOAP based, Visual Studio can generate a proxy for you, so that you don't need to parse the SOAP message.
3) Silverlight has LINQ to XML and LINQ to JSON, which makes parsing both POX and JSON a breeze.
In a perfect world, I would go with Silverlight for the "engine", and fall back to JavaScript in case Silverlight is not available.
Greetings,
Laurent
Another thing to consider - getting your data in JSON format will be faster than XML and Web Services. JSON becomes a JavaScript object pretty quickly and doesn't have to be parsed like XML does. Personally, I'd go with JavaScript.
article: Speeding Up AJAX with JSON
Since JavaScript isn't multithreaded, I'm finding that using Silverlight to access/cache the data then pass it to JavaScript for display produces much better performance, while refraining from locking/freezing the browser so the user can keep doing stuff while the data loads.
Passing JSON-formatted data is in part faster because unlike an XML SOAP message, it doesn't require a SOAP header or any other miscellaneous info - it's just pure data. Thus, making the total size of the message smaller.