Open core-ai-bot opened 2 years ago
Comment by jasonsanjose
Thursday Oct 16, 2014 at 17:25 GMT
A few notes on the security issues we ran into:
file:
URLs (we have shims in place for libraries that require cookies) Comment by peterflynn
Monday Oct 20, 2014 at 20:35 GMT
Initial thoughts.... There's some risk in making Node a more critical part of Brackets, specifically:
I wonder if there are other alternatives that might avoid some of those risks, e.g.:
ClientHandler::HandleBeforeResourceLoad()
to return a LoadStream for a file on disk, which would veto CEF going out to the network to try to resolve the URL. CEF can even create the stream for you, using CefStreamReader::CreateForFile()
. See this and this for some info. Comment by peterflynn
Monday Oct 27, 2014 at 07:50 GMT
Added some more notes on alternatives to my list in the previous comment
Proof of concept to serve brackets core www files over a static file HTTP node server.
After running into various issues with the security model (or lack of) in CEF combined with the issues when using the
file:
protocol, I thought it would be fun to see what it would take to serve Brackets over HTTP within brackets-shell using the built-in node server.Overall, this is not required for any current/planned features. However, I think it would help Brackets get closer to moving into the browser if we could transition away from
file:
first within brackets-shell.Changes:
appshell/node-core/Server.js
NodeConnection
to read the/api
JSON (i.e. http://localhost:[node_port]/api)appshell/node-core/thirdparty/conenct
static
middleware to serve filesThere's still more to do on the www side. We wouldn't need to shift to a node-based FS since we're in brackets-shell and can still access
brackets.fs
. However, a lot of www code (particularly extension loading) assumes afile:
URL. Here's the console log on init:jasonsanjose included the following code: https://github.com/adobe/brackets-shell/pull/475/commits