Tue 22 Feb 2011 02:33:11 PM UTC, comment #11:
I guess we'll stick with what we have now then.
|
Mon 08 Nov 2010 09:38:13 AM UTC, comment #10:
I can confirm that it was due to VM::isInitialized() allowing this check to be omitted for the first SWF.
This was a hack that used a truly awful design to do something quite useful, and now the singletons have all gone there isn't a ready-made way to do it. The options are: stick with what we have now, which is consistent but awkward, or add a way to disable this check and do so for the initial SWF. Any preferences?
|
Mon 08 Nov 2010 08:32:32 AM UTC, comment #9:
But that doesn't explain why -u works for the reporter when -U doesn't.
|
Mon 08 Nov 2010 08:24:37 AM UTC, comment #8:
-u is used as -U if -U isn't given.
|
Mon 08 Nov 2010 08:14:21 AM UTC, comment #7:
It shows I was wrong about the -u not being used to resolve URLs though; I guess this is for movie loads, since we verified that the base URL (-U) is used for loading XML.
|
Mon 08 Nov 2010 08:12:37 AM UTC, comment #6:
It's not about whether it's an allowed resource or not (this is to do with adding a sandbox path, which is still done).
It's the fact that the specified original URL (passed using -u) is a non-local file, yet the first file loaded is a local file, and this is forbidden by the URLAccessManager.
I'm pretty sure we always used to check against this URL. The only difference I can think of is that the static VM::isInitialized() would have evaluated to false at the time of the first check, so the check could be omitted for the first SWF loaded only (i.e. the starting SWF). Now if I can work out how to view older revisions with git I'll try to confirm.
|
Sun 07 Nov 2010 09:57:41 PM UTC, comment #5:
Just to confirm, git bisect blames 1d9727a for the change. Passing the file via STDIN (using '-' for the URL, and -u as well) works.
|
Sun 07 Nov 2010 06:54:16 PM UTC, comment #4:
Yeah, might be annoying. Anyway, use standard input and it'll work.
I belive we used to add the command-line given path to the list of allowed resources for this specific purpose. Duno if we're still doing it.
|
Sun 07 Nov 2010 04:59:30 PM UTC, comment #3:
Having said that, with just '-U', the SWF doesn't run properly when downloaded - it seems to miscalculate the URLs it's looking for.
With 0.8.8, I'm able to change the '-U' for a '-u', and get it to work - with git master, when I do that, I get the SECURITY warning. From my reading of the man page, this is what '-u' is meant for, no?
So I think this behaviour has changed, and might mean there's no reliable way to run downloaded SWFs right now. I'll try to find out which commit changed it.
|
Sun 07 Nov 2010 04:10:32 PM UTC, comment #2:
Well, that's embarrassing - the '-u' wasn't meant to be there (but I'm sure I did try it with just '-U', with the same problem).
Anyway, after a rebuild it all seems to work. I'll let you know if I see it again.
|
Sun 07 Nov 2010 08:05:06 AM UTC, comment #1:
The -U argument should be used to resolve URLs, but shouldn't prevent any SWFs from loading. The -u argument is used to specify a real SWF URL when Gnash loads from a file descriptor. This one is used to decide whether a load is allowed from the filesystem or not. Your command line ought to work if -u isn't specified, and that shouldn't have any other effects on the running of the SWF.
If dropping -u doesn't work, it's a bug. Otherwise, even if the behaviour has changed since 0.8.8, I don't think this is a bug (but would be happy to be convinced otherwise).
|
Sun 07 Nov 2010 12:47:41 AM UTC, original submission:
I'm having trouble running a local copy of a downloaded swf. (I want to be able to edit the swf to isolate testcases from it.)
The two relevant lines in the debug output are:
3398:1] 12:51:21 SECURITY: Checking security of URL 'file:///home/tim/src/gnu/gnash/iplayer/player.swf/player-18269_21576.swf'
3398:1] 12:51:21 SECURITY: Load of file /home/tim/src/gnu/gnash/iplayer/player.swf/player-18269_21576.swf forbidden (starting url http://www.bbc.co.uk/iplayer/episode/b00vky79/Off_the_Page_Living_Cheap/ is not a local resource)
I've attached my two scripts to show how I'm trying to run gnash - 'run' works, but 'run2' gives the above errors. (I haven't attached the cookies file for the moment.) I've tried '-u' instead of '-U', but that didn't seem to help.
I'm using git master (821944e) - run2 seems to work with Debian's 0.8.8 package, so this might have been a recent regression. I'm currently suspecting commit 1d9727ab (removing VM singleton) which touched the function containing that error message - but haven't bisected to prove this yet.
|