![]() ![]() During development go.rice will load required files directly from disk. > go.rice is a Go package that makes working with resources such as html,js,css,images,templates, etc very easy. To clarify, the description for go.rice is: Maybe I misunderstood what you were asking. Also this sounds like something you should be doing with your build tools., can't include something in the binary at runtime. "flipping a production switch" is a pretty application-specific endeavor. I didn't address your question about go.rice - from what I know, it doesn't have this kind of thing built in, and I don't know that it even should. I actually thought that's what Rouille ( ) was, which was mentioned in the blog post, but it looks like just uses the macro from that package (to include the strings), not the actual library even, since at the end of the day he opts for rocket ( ) Project Zero is finding lots of local HTTP servers that are reachable from web pages. That's how DNS rebinding attacks work and host header checking is one way to for the local web server to prevent other pages from accessing it. I can have a page on :5000 and set the DNS zone to a really low TTL change its A record to think it's 127.0.0.1 after first load thereby letting the browser think I'm same origin w/ just an IP change, then I can ajax call to :5000 to access the local daemon. You can employ other methods to ensure the client is "authenticated" to use the server. It's one way to prevent DNS rebinding attacks. > Why should a desktop app even care about host headers? ![]() If you're asking "why not build your app on gtk instead of web tech?": there are a million reasons and this question happens frequently, so not really sure it's worth rehashing here. If you're asking "why not link to gtk webkit?": because I don't want to statically compile or ship with the entire browser (not to mention Windows compat). > With all that work why not just link to gtk and build on that? In the meantime, just hope these OS engines stay minimal and don't fall too far behind the standards you want. To sum up my rant, I'm afraid the fast moving web stack, coupled with the fact only a few companies can keep up, coupled with the fact that those companies are laser focused on their own browser use case and not embeddability combine to make this incredibly common desktop use case still suck. So for that, the Chromium project would have to prioritize better runtime feature gating for mem reduction and maybe revive first-class support for single-process mode, which I doubt they'd do. And it still doesn't solve the extremely mem-bloated approach they take to serving the web stack. I'd say if you want this, the Chromium project would have to prioritize a stable Chrome ABI from their shared lib which I doubt they would do. Electron has deep requirements on Chromium for V8, IPC, webview, customer protocol handlers, etc IIRC so it can't just easily switch browser engines. Well, Chrome doesn't really allow chrome.dll to be easily used. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |