Skip to content
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

feat(unstable): Support data: urls #5157

Merged
merged 16 commits into from
Sep 11, 2020
Merged

feat(unstable): Support data: urls #5157

merged 16 commits into from
Sep 11, 2020

Conversation

SyrupThinker
Copy link
Contributor

Closes #5059

Notes:

  • percent-encoding is already an indirect dependency of url
  • The disk cache name might need revising
  • Graceful failure is probably desired in extract_data_url, what kind of Error should be returned?

Copy link
Contributor

@kitsonk kitsonk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens with media types we don't support, like text/plain? It would be good to have some non-happy path tests for this.

@SyrupThinker
Copy link
Contributor Author

What happens with media types we don't support, like text/plain? It would be good to have some non-happy path tests for this.

Currently they get treated as JavaScript because it falls through here:

deno/cli/global_state.rs

Lines 146 to 149 in fca204d

_ => Ok(CompiledModule {
code: String::from_utf8(out.source_code)?,
name: out.url.to_string(),
}),

@kitsonk
Copy link
Contributor

kitsonk commented May 8, 2020

Hrmmm... I didn't think we allowed media types we didn't know. @bartlomieju are we sure we want that? Seems like a big security hole.

Non-happy path tests would still be good.

@SyrupThinker
Copy link
Contributor Author

Non-happy path tests would still be good.

Working on that and checking whether removing that fallback causes regressions

@SyrupThinker
Copy link
Contributor Author

I'd like to have some feedback on how to handle extract_data_url and unknown media type failure first because the non-happy test results depend on that.

Copy link
Member

@ry ry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting feature. The patch looks cleanly implemented.

How are data-urls used with javascript typically? I don't understand the use case.

Do data urls work like this in Chrome?

cli/tests/integration_tests.rs Outdated Show resolved Hide resolved
@SyrupThinker
Copy link
Contributor Author

SyrupThinker commented May 9, 2020

How are data-urls used with javascript typically?

The usages I encounter are generally data embedding.

Do data urls work like this in Chrome?

Both Firefox and Chrome allow imports of that form.
This implementation diverges in behaviour when the data url is malformed or has an incompatible media type.
The browsers throw a type error, this currently panics for the former and treats it as JavaScript in the latter.

@ry
Copy link
Member

ry commented May 9, 2020

Ok sounds good.

I think we should make this an unstable feature for the time being. I'd leave it up to you to figure out how to do that exactly (if you don't mind). Here's reference:

deno/cli/state.rs

Lines 236 to 248 in 2b02535

/// Quits the process if the --unstable flag was not provided.
///
/// This is intentionally a non-recoverable check so that people cannot probe
/// for unstable APIs from stable programs.
pub fn check_unstable(&self, api_name: &str) {
// TODO(ry) Maybe use IsolateHandle::terminate_execution here to provide a
// stack trace in JS.
let s = self.0.borrow();
if !s.global_state.flags.unstable {
exit_unstable(api_name);
}
}
}

@bartlomieju
Copy link
Member

Thanks for the patch @SyrupThinker; however I think we should wait on this PR after 1.0 is released and compiler refactor is finished.

It introduces yet another layer to consider and if I'm not mistaken data imports are dependent on location/origin which we currently don't support.

Hrmmm... I didn't think we allowed media types we didn't know. @bartlomieju are we sure we want that? Seems like a big security hole.

That's how it always worked: unknown media types are treated as if they were JS which in most cases ends up in an error from V8 or TS compiler.

@SyrupThinker
Copy link
Contributor Author

SyrupThinker commented May 9, 2020

Ok, I'll continue working on this after the refactor then.

@bartlomieju bartlomieju added cli related to cli/ dir feat new feature (which has been agreed to/accepted) labels May 15, 2020
@bartlomieju bartlomieju added this to the 1.1.0 milestone May 21, 2020
@ry ry requested a review from bartlomieju June 6, 2020 17:52
@SyrupThinker
Copy link
Contributor Author

It introduces yet another layer to consider and if I'm not mistaken data imports are dependent on location/origin which we currently don't support.

That is correct; we certainly don't want to allow circumventing restrictions by imports like https > data > file or https > data > http.

This is done to prevent modules from being able
to proxy forbidden imports through data.
This should be replaced with proper origin tracking
at a later time.
@ry ry modified the milestones: 1.1.0, future Jun 10, 2020
@CLAassistant
Copy link

CLAassistant commented Jul 27, 2020

CLA assistant check
All committers have signed the CLA.

@ry
Copy link
Member

ry commented Aug 18, 2020

@SyrupThinker I'm sorry we didn't get this landed earlier. If you can get this rebased on master, I would include it in 1.4.0 (to be released September 13)

@ry ry modified the milestones: future, 1.4.0 Aug 18, 2020
@ry
Copy link
Member

ry commented Aug 31, 2020

Since the main use case for this feature is for loading workers, it would be good to have a test case demonstrating that you can start a worker with a data url.

@SyrupThinker
Copy link
Contributor Author

I don't know how to resolve the tsc errors (or how to debug them), could use some help for that.

For example I can't figure out how to log stuff in cli/tsc/00_typescript.js.

Copy link
Member

@bartlomieju bartlomieju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MDN tells that data: URLs are not allowed at top level due to phishing vulnerability. I wonder if we also should disallow them as entry point 🤔

EDIT: I guess it doesn't make much difference - we still require --allow-* flags.

cli/tests/integration_tests.rs Outdated Show resolved Hide resolved
@@ -687,6 +687,7 @@ impl TsCompiler {
self.file_fetcher.clone(),
global_state.maybe_import_map.clone(),
permissions.clone(),
global_state.flags.unstable,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we need to hide it behind unstable

@bartlomieju
Copy link
Member

@SyrupThinker I have fixed the tests. TS failures were caused by #7392

@bartlomieju bartlomieju changed the title Add support for importing data url's feat: Support data: urls Sep 11, 2020
Copy link
Member

@bartlomieju bartlomieju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you @SyrupThinker

@bartlomieju bartlomieju changed the title feat: Support data: urls feat(unstable): Support data: urls Sep 11, 2020
@bartlomieju bartlomieju merged commit e3319f3 into denoland:master Sep 11, 2020
@SyrupThinker SyrupThinker deleted the data_imports branch September 11, 2020 21:13
bartlomieju added a commit to bartlomieju/deno that referenced this pull request Sep 12, 2020
bartlomieju added a commit that referenced this pull request Sep 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli related to cli/ dir feat new feature (which has been agreed to/accepted)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support importing data URLs
5 participants