Open ernesto-jimenez opened 8 years ago
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).
hi @kirillDanshin
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:
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
.
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.
@kirillDanshin the server is only going to have one client: the gallium app. Going with fasthttp
is an overkill :)
its too early for fasthttp. Why ?
The idea of a good base that allows websockets, route handlers is great though. What framework were you wanting to use ?
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.
@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.
I am with @ernesto-jimenez and also I believe that HTTP routers should not be in the scope of this issue.
@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.
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.
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.
There will be different security requirements for the HTTP connections from
libchromiumcontent
.libchromiumcontent
has access to.libchromiumcontent
has access to.libchromiumcontent
and the embedded server.@alexflint, I have some ideas about how to address this, I can create issues for each of these points and outline some proposals if you want.