-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Address Issue174 #200
Conversation
Rewrite addResource to be testable and export it.
src/sandbox/external-resources.js
Outdated
return getContentType(resource).then(contentType => { | ||
if (contentType.indexOf('text/css') === 0) { | ||
addCSS(resource); | ||
} else if (contentType.indexOf('application/javascript') === 0) { |
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.
application/javascript
is not the only content type for javascript source code, see here.
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.
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.
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 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.
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.
OK. In that case, we can probably just go ahead and add the whole list.
Very nice! Thanks a lot 😄 . Also very nice that you wrote the tests.
Hmm strange, I'd expect the error overlay to come up. I'll do some testing in a min. |
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! |
@CompuIves I like it. I'll also add the extra checks. |
@CompuIves @lbogdan Thanks for all the feedback! I've updated the code and tests. Is there anything else to be done? |
Yep, one small thing left! Could you add yourself to the contributors by running:
|
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) |
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? |
Let's say you have an URL without a It still gets added to the sandbox, but that's only because there's no error checking. |
@tansongyang To answer your other question
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 The API is currently closed source, so this is something only @CompuIves can do for now, at least on the API side. |
@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? |
@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. |
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. |
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. |
Hmm, we should add the resource regardless because we can't deny access to resources that don't have their cors headers on allow... |
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. |
@CompuIves The check should only be for resources that don't end in |
Now that we can load scripts and style-sheets directly from |
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. |
Closed because of lack of activity |
These commits address issue #174 . A few points:
eslint
because it complained about line endings (I'm on Windows). We could always add a.gitattributes
file to letgit
enforce this instead ofeslint
. This would make it easier for people on Windows to contribute. I can PR if you agree.