I have crawled the web quite a lot these days, but couldn't get any accurate information on how crossdomain.xml files behave in case of 302 redirects; especially with the sandboxes having changed significantly over the last versions!
I am relatively new to flash... so any advice is more than appreciated!
I have been working on a project lately that uses audio streams with some sort of CDN distribution! what happens is that a common url is triggered, and then the user is dynamically redirected to the next best server available. In my case, i have no access at the server side of things (at least not anytime soon). And the only path providing an appropriate crossdomain.xml is the one performing the redirect. All the other dynamic paths provide exclusively content!
http://resource.domain.com (valid crossdomain.xml)
302 => http://dyn1.domain.com/...
302 => http://dyn2.domain.com/...
302 => http://dyn3.domain.com/...
I noticed that flash doesn't care much if i try to load the audio stream with something like...
var req :URLRequest = new URLRequest("http://resource.domain.com");
var sound :Sound = new Sound(req); // ie. effectively playing http://dyn3.domain.com
sound.play();
It gets both redirecting, and streaming done well! and doesn't bother for any crossdomain file and starts playing!
Although when i try something different, like setting up some custom headers to the request and loading the file with URLStream instead, everything gets messy! Well, the redirect gets done, as expected but all of a sudden i need another crossdomain file in the redirected location!
Is there any explanation to whats happening and eventually ways to resolve this?!
Thanks for your time!
It comes as a site question : i noticed everything to work flawlessly while being in the local-trusted sandbox and errors happening mainly if not exclusively in the remote sandbox. is it possible that the local-trusted sandbox doesn't care about crossdomain policy files at all!?
Summary
Add crossdomain.xml to each CDN host or adopt to limited Sound functionality.
Details
SWF files that are assigned to the local-trusted sandbox can interact with any other SWF files and can load data from anywhere (remote or local).
Sound can load stuff from other domains that don't allow access using cross-domain policy with certain restrictions:
Certain operations dealing with sound are restricted. The data in a
loaded sound cannot be accessed by a file in a different domain unless
you implement a cross-domain policy file. Sound-related APIs that fall
under this restriction are Sound.id3, SoundMixer.computeSpectrum(),
SoundMixer.bufferTime, and the SoundTransform class.
Flash in general has pretty complex cross-domain policies but in your case the bottom line is that you'll need to have proper crossdmain.xml on each host except the one that serves the SWF:
3.1. If your file is served from http://resource.domain.com it's not required to have http://resource.domain.com/crossdomain.xml but it's really good to have one.
3.2. You will need to have proper http://dyn2.domain.com/crossdomain.xml explicitly allowing your SWF to access dyn2.domain.com to be able to use URLLoader and other APIs that provide access to raw loaded data.
3.3. There's a reason for these restrictions - cookies (and other ambient user credentials). If Flash would not require proper cross-domains after a redirect, one could access any domain with user cookies attached by simply loading his own redirector first. This means accessing all user cookie-protected data (e.g. mail.google.com) from any SWF on the internet that's running in your browser.
Related
I'm making a game that changes some of it's object depending on what music is playing. After each song has ended I want my audio context to load in a new source and analyze that. However whenever I tried to do that I've gotten the error that an audio object or buffer can't be called twice.
After some researching I learned that ctx.createMediaElementSource(MyHTML5AudioEl) lets you create a sourceNode that takes the source from a HTML5 object. With this I was able to loop through different song.
However for my game I need to play/analyze a 30 seconds "remote url" that comes out of the Spotify API. I might be wrong but ctx.createMediaElementSource(MyHTML5AudioEl)does not allow you to analyze a source that is on a remote site.
Also the game needs to work on Mobile Chrome, which createMediaElementSource(MyHTML5AudioEl) does not seem to work on.
I might be on the completely wrong path here but my main question is:
How can I switch remote songs urls in web audio api. With it being compatible with mobile chrome.
Thanks!
First, as you found out, you can't set the buffer again for an AudioBufferSource. The solution is to create a new one. AudioBufferSources are intended to be light-weight objects that you can easily create and use.
Second, in Chrome 42 and newer, createMediaElementSource requires appropriate CORS access so you have to make sure the remote url sends the appropriate headers and you set the crossOrigin attribute appropriately.
Finally, Mobile Chrome currently does not pass the data from an audio element through createMediaElementSource.
I have a web app that stores videos. I am using a java servlet (over https) which verifies a username and password. Once the details are verified, i redirect the user to a video stored in AWS S3. For those who don't know how S3 works, its just a web service that stores objects (basically think of it as storing files). It also uses https. Now obviously to make this work, the s3 object (file) is public. I've given it a random name full of numbers and letters.
So the servlet basically looks like this:
void doGet(request, response){
if (authenticateUser(request.getParameter("Username"), request.getParameter("Password")){
response.sendRedirect("https://s3.amazonaws.com/myBucket/xyz1234567.mp4");
}
}
This is obviously simplified but it gets the point across. Are there any very obvious security flaws here? The video tag will obviously have a source of something like https://www.mysite.com/getVideo?Username="Me"&Password="randomletters". At first blush it seems like it should be as secure as anything else assuming i give the file names sitting at AWS s3 sufficiently random names?
The obvious security flaw is that anybody could detect which URL the authentication servlet redirects to, and share this URL with all his friends, thus allowing anyone to access the resource directly, without going through the euthentication servlet.
Unfortunately, I don't know S3 at all, so I can't recommend any fix to the security problem.
All this mechanism does is provide a very limited obfuscation - using developer tools in most modern browsers (or a proxy such as Fiddler) a user will be able to watch the URL of the video that's being loaded and, if it's in a Public S3 bucket, then simply share the link.
With S3 your only real solution would be to secure the bucket and then either require that the user is logging in or use the temporary tokens for access [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] ... though this does complicate your solution
I would also mention that including the password and username in plaintext on the link to the video asset (from the question above) is very insecure
(ActionScript3) Hi, I'm trying to work out why a URLRequest is failing when viewed via a third party website. Ideally any error could be pointed out in the below code, however, I think it's fine as similar things we do work fine.
Next to ideal would be URLRequest error handling, how can I find out WHY the URLRequest is not pulling the information from time.php? Even if it's just output to a textbox on the timeline (everything works fine when done from the testing environment)
Many thanks
Craig
Scenario:
domain.com (Server 1): file.swf uses a URLRequest to load domain.com/time.php?a=b (so the PHP and the SWF are both hosted on the same domain and server)
example.com (Server 2): PHP page embedding file.swf (which in turn URLRequests time.php)
Outcomes:
When you access file.swf directly via browser, it loads the data from time.php just fine
When you view the page file.swf is embedded on, on Server 2 the loading fails
file.swf
var loaderNameHolder;
var loaderNameHolderLoader:URLLoader = new URLLoader();
var loaderNameHolderURLRqst:URLRequest = new URLRequest('http://domain.com/time.php?a=b');
loaderNameHolderLoader.addEventListener(Event.COMPLETE, loaderNameHolderURLFunc);
loaderNameHolderLoader.load(loaderNameHolderURLRqst);
function loaderNameHolderURLFunc(e:Event):void{
loaderNameHolder = loaderNameHolderLoader.data
gotoAndStop(loaderNameHolder);
}
Security
There is a crossdomain XML in place on the domain's root folder, it seems to make no difference (or is not being referenced/used correctly) however as mentioned similar things I do work fine without modifying this XML
It sounds like a security issue, although you say that you have the crossdomain file in place.
Have you checked the http calls with a tool like Charles (http://www.charlesproxy.com/)? This is definitely the best way to debug such a problem.
Thanks for the tips above, they'll be great resources to keep.
The actual issue was that the Requested URL didn't include "www" (I think because the SWF is embedded with the WWW so it was coming from an "outside" domain. I think I need www.domain.com in my own security XML).
Craig
try adding this code
Security.allowDomain("*");
Security.loadPolicyFile("http://domain.com/crossdomain.xml");
and read about crossdomain.xml using links given here: https://stackoverflow.com/a/9728845/2234089
Really puzzled by the flaky behavior of LocalConnection.
Using a debug utility(LuminicBox) that uses localConnection to work.
When the page containing the swf is loaded in a browser locally , localConnection works.
When the identical page and swf are viewed 'live' on a remote site, localConnection fails.
Anyone encounter this??
By default LocalConnection allows communication between swfs loaded from the same domain. When you're loading the swf in the browser, the debug utility also has to be loaded in the browser from the same domain.
You can get LocalConnection to work across domains but it requires more configuration. Here's a link to Flex's docs on the subject. This issue is the same for Flash/Flex.
http://livedocs.adobe.com/flex/3/langref/flash/net/LocalConnection.html
I haven't used LuminicBox, but if you have access to the code that initializes the receiving LocalConnection object, call allowDomain("your.domain") on that object.
var lc:LocalConnection = new LocalConnection()
lc.allowDomain("your.domain.com");
//or even better - allow all domains
lc.allowDomain("*");
If the receiving SWF is hosted on an HTTPS page and the sender on a normal page, you need to call allowInsecureDomain.
lc.allowInsecureDomain("your.domain.com");
I think part of the problem is that I DON"T have access to the code that initializes the receiving LocalConnection object, just the sending LC (my application).
I would assume though, that the author of the debug utility would have definitely used lc.allowDomain("*"); Will check further.
The only other cause I am aware of is having an existing LC connection already open, when you try and open a new one.
we have a small flash component on our website/application to upload multiple files.
This works fine, however we want to get the Content-Type from the headers and its always set to 'application/octet-stream'. From what I've learned this is due to a security of flash sandbox and FileUpLoad will never give this to us.
Is there any other way we could do this in flash (aside from creating an html/ajax multi file upload)?
many thanks
We have had a simlar problem when uploading from a browser. What is sent in the content type is dependent upon the browser and what is installed on the client machine. If it is an extension that the client machine does not recognise it will come back as application/octet-stream.
What we ended up doing was creating mapping functionality from the file extension to the content type. That way we could ensure consistency.