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

Address Issue174 #200

Closed
wants to merge 5 commits into from
Closed

Address Issue174 #200

wants to merge 5 commits into from

Conversation

tansongyang
Copy link
Contributor

@tansongyang tansongyang commented Sep 15, 2017

These commits address issue #174 . A few points:

  1. I couldn't run eslint because it complained about line endings (I'm on Windows). We could always add a .gitattributes file to let git enforce this instead of eslint. This would make it easier for people on Windows to contribute. I can PR if you agree.
  2. I notice that, even if there is an error, the URL still gets added in the UI. Do you want to prevent that, or leave things as they are?

return getContentType(resource).then(contentType => {
if (contentType.indexOf('text/css') === 0) {
addCSS(resource);
} else if (contentType.indexOf('application/javascript') === 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

application/javascript is not the only content type for javascript source code, see here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

According to my research, application/javascript is official. We could also add application/ecmascript, since it seems like it's in use. The text/ ones are deprecated. Do you think it's OK to leave them out? The rest seem obscure.

Copy link
Contributor

Choose a reason for hiding this comment

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

I looked at the 'Content-Type' header for the scripts in a bunch of random websites, and the results were all over the place, from application/javascript, to text/javascript, to application/x-javascript etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK. In that case, we can probably just go ahead and add the whole list.

@CompuIves
Copy link
Member

Very nice! Thanks a lot 😄 . Also very nice that you wrote the tests.

I notice that, even if there is an error, the URL still gets added in the UI. Do you want to prevent that, or leave things as they are?

Hmm strange, I'd expect the error overlay to come up. I'll do some testing in a min.

@CompuIves
Copy link
Member

CompuIves commented Sep 15, 2017

Okay! Tested it, works great. I agree with @lbogdan that we should add the other checks to be sure.

I made a small change: now we catch the errors and show it to the user + we check if the resource exists.

Curious what you think!

@tansongyang
Copy link
Contributor Author

tansongyang commented Sep 15, 2017

@CompuIves I like it. I'll also add the extra checks.

@tansongyang
Copy link
Contributor Author

@CompuIves @lbogdan Thanks for all the feedback! I've updated the code and tests. Is there anything else to be done?

@CompuIves
Copy link
Member

Yep, one small thing left! Could you add yourself to the contributors by running:

npm run add

@lbogdan
Copy link
Contributor

lbogdan commented Sep 16, 2017

While doing some testing, I encountered a corner(?) case: what if the server that hosts the script / stylesheet doesn't have CORS enabled?

(that's why I said in the issue that it would have been much nicer for this to be handled in the API)

@tansongyang
Copy link
Contributor Author

tansongyang commented Sep 16, 2017

HI @lbogdan, could you please clarify what you mean by having this handled by the API? Could you also share the URL that produces the issue?

@lbogdan
Copy link
Contributor

lbogdan commented Sep 17, 2017

Let's say you have an URL without a .js (or .css) extension, but which returns javascript (or css), together with correct Content-Type header (example: javascript / css). Because that server doesn't send CORS headers, when trying to add it as a resource I get this:

It still gets added to the sandbox, but that's only because there's no error checking.

@lbogdan
Copy link
Contributor

lbogdan commented Sep 17, 2017

@tansongyang To answer your other question

could you please clarify what you mean by having this handled by the API?

When adding a resource, there's an "add resource to sandbox" API call with the resource URL, and while serving that request the API could check the content type of the resource and return it in the response (or return an error if not a valid content type, which could be very easily handled by the UI). Also, in all other API responses ("get sandbox", "get sandbox's resources"), resources should be returned as { url, type }.

The API is currently closed source, so this is something only @CompuIves can do for now, at least on the API side.

@tansongyang
Copy link
Contributor Author

tansongyang commented Oct 3, 2017

@lbogdan @CompuIves Just checking on the status of this PR. Do we want to scrap this and go with the API approach? Or keep it as it is and find a different solution for the case where the server doesn't have CORS enabled?

@lbogdan
Copy link
Contributor

lbogdan commented Oct 3, 2017

@tansongyang I don't really have any say in this, but if I had, I'd go with the API approach. For me it makes the most sense for the API to return the list of external resources, including their types (also, to figure out the type of a resourse, and to validate it on add). The only issue with that is that, as far as I know, @CompuIves' focus is currently on other functionality.

@CompuIves
Copy link
Member

I agree that the API approach is most desirable. I'll probably work on that somewhere around December.

Until then we can use this approach and default to the old behaviour if we encounter a CORS issue.

@lbogdan
Copy link
Contributor

lbogdan commented Oct 9, 2017

Before merging, I think we should fix the issue with the resource being added anyway, even if there was an error (invalid content type or CORS). I took a quick look and saw that the resource is first added to the sandbox (through an API call), and only then loaded. We should probably do the check before adding it to the sandbox.

@CompuIves
Copy link
Member

Hmm, we should add the resource regardless because we can't deny access to resources that don't have their cors headers on allow...

@tansongyang
Copy link
Contributor Author

tansongyang commented Oct 10, 2017

I think it's fine to just allow it as well. Isn't that what codesandbox used to do? Adding more checks seems like it's beyond the scope of this PR, which was originally intended just to allow things like Google fonts.

@lbogdan
Copy link
Contributor

lbogdan commented Oct 10, 2017

@CompuIves The check should only be for resources that don't end in .js or .css, those will work regardless. For the rest, even if we allow them to be added to the sandbox, they will error when we try to check their content type, and won't work.

@lbogdan
Copy link
Contributor

lbogdan commented May 1, 2018

Now that we can load scripts and style-sheets directly from index.html, should we pursue this further?

@stale
Copy link

stale bot commented Dec 3, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale? label Dec 3, 2018
@SaraVieira SaraVieira removed the stale? label Jan 8, 2019
@SaraVieira
Copy link
Contributor

Closed because of lack of activity

@SaraVieira SaraVieira closed this Jan 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants