Comments (11)
@kirillDanshin the server is only going to have one client: the gallium app. Going with fasthttp
is an overkill :)
from gallium.
no, please, don't use net/http
, it's slowing down your performance (take a look on fasthttp).
as soon as I can run gallium on linux, I'll write some default handlers and boilerplate code so you will be able to use something like gallium.NewApp
function and register some route handlers, websocket handlers etc. in it.
also it will secure traffic between the app and libchromiumcontent automatically and it will be optimized to get maximal security while saving or improving performance.
also I think that developer should be able to disable whitelisting and allow all domains, if he want.
from gallium.
@kirillDanshin I'm a newbie developer and just dropping in to say that I basically agree with @kirillDanshin . I have used iris in 3~4 of my older projects at the company where I work and we basically decided to replace it with Iris which uses fasthttp.
It's truewhat @ernesto-jimenez says regarding fasthttp being an "overkill", however, if there is something better that we can do, why not do it?
It's your project so I am certain you will choose to do what suits you the best, but my recommendation and request is to use fasthttp until net/http gains the performance optimizations that we see in fasthttp package.
Kind regards, thank you for the wonderful project "Gallium". I cannot wait for it to be ported to Ubuntu and Windows.
from gallium.
@ernesto-jimenez thanks for starting this conversation! Sorry for coming so late, I've been knee deep in the chromium codebase :)
Restricting what domains/URLs libchromiumcontent has access to.
I agree this is important. One option would be to investigate what chromium itself can do for us here. I believe there is a way to intercept and override page loads using one of the WebContents callbacks. I would be interested in your suggestions on this
Starting an HTTP server embedded in the app that only libchromiumcontent has access to.
Agreed, although for starters I think we should just focus on setting up a reliable communication channel between go and js (e.g. how does js find out what endpoint to contact the go server on? What if there are multiple instances of the same gallium app, how do they avoid trying to bind to the same port?)
Preventing sniffing of the traffic between libchromiumcontent and the embedded server.
I actually wonder if we should leave this for later on. Whenever you ship code to run on a user's computer I think you should assume that a motivated adversary will eventually disassemble all your client-side code and discover all its secrets, so projects that use gallium should never rely on it keeping adversaries out on the client side. I do think it's worth having some countermeasures to make this as difficult as possible, but I suspect we can leave this until later.
from gallium.
I didn't get your point in 1.
. Why we're required to do that?
Also, I think that 2.
may be done only as an option because developers could use the server from other microservices if they want.
But I absolutely agree and support 3.
. Also, it can be done, for example, with IETF RFC7539 (also known as ChaCha20 and Poly1305).
from gallium.
I didn't get your point in 1.. Why we're required to do that?
It is pretty standard to whitelist the domains your web view can access. E.g., information from the Cordova project (PhoneGap) about this: http://cordova.apache.org/docs/en/latest/guide/appdev/whitelist/index.html
If you allow your web view to access anything, there is a bunch of security and UX considerations:
- What happens if you get redirected to some other page due to a mistake in the app? How do you get back to the app's web page without a back button or an address bar?
- Could an attacker make the gallium app load an untrusted domain?
- If a malicious actor can trick the user/app into loading an untrusted domain, Is there a risk for phishing? How could the user be aware without an address bar? What other risks are there?
Also, I think that 2. may be done only as an option because developers could use the server from other microservices if they want.
Developers will always be able to spin up their servers from a gallium app.
By default, however, I would have gallium
start a web server using its own http.Handler
that handles authentication before forwarding the request to http.DefaultServeMux
. With that setup, libchromiumcontent
would point by default to that server.
You would always be able to start a second server serving http.DefaultSeveMux
or anything else. But then it is up to you to manage authentication and security.
But I absolutely agree and support 3.. Also, it can be done, for example, with IETF RFC7539 (also known as ChaCha20 and Poly1305).
I'm sure there must be a way. It's probably just a matter of looking into what is supported by libchromiumcontent
.
from gallium.
its too early for fasthttp. Why ?
- echo framework dropped support for fasthttp. See issue 665. They found that its was way too much work to support it as things go bigger.
- For a single user environment, the perf difference will be not worth it. I agree with @ernesto-jimenez .
- We have bigger fix to fry still. We can start with standard, and then later do fasthttp IF some want it.
The idea of a good base that allows websockets, route handlers is great though.
What framework were you wanting to use ?
from gallium.
I don't use echo framework because it works disgusting and can't handle even 10% of project's workload. I don't use net/http because it terribly ineffective. I want to give developers a simple API while using lowest as possible resources and give the best performance so they can give end users the best user experience ever. I can do it that way and keep API as simple and stable as possible. if you really want, we can support both fasthttp and net/http.
from gallium.
I am with @ernesto-jimenez and also I believe that HTTP routers should not be in the scope of this issue.
from gallium.
Restricting what domains/URLs libchromiumcontent has access to.
I agree this is important. One option would be to investigate what chromium itself can do for us here. I believe there is a way to intercept and override page loads using one of the WebContents callbacks. I would be interested in your suggestions on this
I have never worked with chromium, so I can only speculate. If libchromiumcontent allows filtering requests, that would be an option. Another option could be to configure a proxy for libchromiumcontent and have it setup to be one started within the Go app.
Starting an HTTP server embedded in the app that only libchromiumcontent has access to.
Agreed, although for starters I think we should just focus on setting up a reliable communication channel between go and js (e.g. how does js find out what endpoint to contact the go server on? What if there are multiple instances of the same gallium app, how do they avoid trying to bind to the same port?)
See #20 for a proposal on how to implement it. It addresses all your concerns except for communication from Go to JS, which is straightforward and I can tackle next.
Preventing sniffing of the traffic between libchromiumcontent and the embedded server.
I actually wonder if we should leave this for later on. Whenever you ship code to run on a user's computer I think you should assume that a motivated adversary will eventually disassemble all your client-side code and discover all its secrets, so projects that use gallium should never rely on it keeping adversaries out on the client side. I do think it's worth having some countermeasures to make this as difficult as possible, but I suspect we can leave this until later.
It would be worthwhile to check what are the configuration options for libchromiumcontent
regarding TLS. If it allows adding a Root CA certificate, securing the traffic with the embedded server would be trivial since we would be able to use a generated self-signed cert.
from gallium.
I agree this subject area is very important.
The idea of doing the security at the libchromium level is nice, because it 100℅ avoids the golang router so people can use whatever they like.
from gallium.
Related Issues (20)
- Build MSI for Windows
- Screen Capture HOT 2
- Form text inputs not responding in go run HOT 2
- Trouble installing: "could not determine kind of name for C.CBytes" HOT 2
- example/controller: after "Miniaturize" & restore, screen is blank HOT 1
- Gallium, file was built for unsupported file format HOT 5
- Is gallium not being actively worked on - as of 2017 HOT 2
- Add more video codecs to chromium layer HOT 3
- what is the status of this project? dead or live? HOT 6
- Breach and Thrust??
- Platform in background?
- LSOpenURLsWithRole() failed with error -10810 HOT 2
- what time will support windows? HOT 1
- Run Quickstart Error HOT 1
- gcc: error: unrecognized command line option '-mmacosx-version-min=10.8' HOT 1
- How does one build gallium from libchromiumcontent
- browser shortcuts and keybinding events are not working properly
- MacOS Termination Reason: DYLD, [0x1] Library missing HOT 7
- installation problem HOT 1
- go get error HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gallium.