New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
avm1: Partially implement FileReference (Part of #307) #5086
Conversation
At the moment, I think we ignore the security framework (e.g. on I think that this doesn't matter so much: |
If you consider it ok, I can implement the other ones as well for the pull
request.
…On Tue, Aug 17, 2021, 18:42 Chris Midgley ***@***.***> wrote:
The download and upload have security implications, so I'm not sure how to
take them into consideration (if the framework is implemented at all).
At the moment, I think we ignore the security framework (e.g. on LoadVars
or XML).
I think that this doesn't matter so much: download is effectively a GET
of a given URL, and upload a POST: if a user can do these inside Flash,
they can also do them outside Flash, so I don't find it terribly concerning
if Ruffle just does these ignoring the sandboxing.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5086 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACYQXXPEPHPAAQNJ46JRQFTT5J7NLANCNFSM5CJWOB3A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
I think that would be nice :) In terms of SWFs in the wild using this: I know of one web-based management interface that uses |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments on the desktop file selector also apply to the web one. A lot of the code is shared: can it be moved up a level somehow?
Regarding the security checks: our intention on web is to not open up any new web attack surface, so on the web we don't need to run the same security checks for On desktop the story changes a little. Flash movies on desktop inherently don't come with an origin. The original security model for local file access was web-only or filesystem-only, controlled with some movie metadata. This is a restriction we absolutely don't implement right now. When we implement |
Well, technically yes, but no :) I could put in core but there are no other implementations of obviously ui code there... if other people also think so, I can move it. |
I don't think I'm going to implement the download/upload pair in this pull request. After an answer to the duplication of the ui code, I'll rebase this and consider this complete for now. |
You have a leftover |
deb1592
to
563b6a8
Compare
563b6a8
to
a587fc1
Compare
I think the PR is good. One question from reading the docs:
Do we have a guard against that? What would happen if we called Also notes for the future:
We'll probably need a guard against that, when we get
Ideally we should implement this at some point, but it's probably not a big immediate risk - since FP blocked this behavior, I don't think people bothered to even try to trigger this without user event. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'd appreciate if kmeisthax looked at the async portion too, but I think it's mergeable as-is)
Since this uses |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
impl<'gc> From<u64> for Value<'gc> { | ||
fn from(value: u64) -> Self { | ||
Value::Number(value as f64) | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get nervous about these kind of conversions, because u64
-> f64
can be lossy and from::From
by convention should be a lossless conversion. But we already have From<usize>
, so this is fine for now.
desktop/src/ui.rs
Outdated
|
||
impl DesktopFileDialogResult { | ||
pub fn new(handle: Option<FileHandle>) -> Self { | ||
let md = handle.as_ref().and_then(|x| metadata(x.path()).ok()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style nit: Let's import fs::self
and then do fs::metadata
(makes it a little clearer that it's the standard metadata fn and not our own fn.)
#[cfg(not(target_arch = "wasm32"))] | ||
fn creation_time(&self) -> Option<DateTime<Utc>> { | ||
unreachable!(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make two separate impl
blocks and #[cfg(not(target_arch = "wasm32"))]
on the impl block, instead of doing #[cfg]
on each method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are functions that should be in both configs and functions that should be in just one. Since I can't do two trait implemenrations, it means I have to duplicate the functions that are in both... advice?
Also, looks like there's an undocumented
No clue what they do, but we should at least mention these in a comment and/or possibly stub them out. |
a587fc1
to
a53ca44
Compare
I've fixed most of the issues you've raised except the cfg thing.
|
a53ca44
to
a8c0b4d
Compare
I intentionally designed it in a way that is easy to customize, so you don't have to stick to that in case you don't like it, you can just provide CSS styles for IDs that RFD is using Default style can be used as a reference: https://github.com/PolyMeilex/rfd/blob/master/src/backend/wasm/style.css |
a8c0b4d
to
017daa4
Compare
017daa4
to
8ee8200
Compare
8ee8200
to
bde69ab
Compare
I've implemented mostly just the browse function which opens a file dialog. The download and upload have security implications, so I'm not sure how to take them into consideration (if the framework is implemented at all).
For the dialog, I've added the rfd crate. It allows for asynchronous file dialogs which the tiny dialog crate don't have, and are part of the spec according the docs.