OK. This has caused quite the controversy here. I do not really want to hurt or upset anybody, and I understand a lot of your concerns about security and safety.
By now I've believe I've made my case on why I would like to pursue an in-browser approach. I'm just going to take one last chance to go over some common concerns about using a local HTTP server, with some proper responses to go on record. After this, I'm going to delay working on upgrading and the "extension management" parts of the shell, and instead focus on the app store-y parts: comments, ratings, code review, uploading, and a proper look. Well, ready? Here we go: == Security == Q: Will this server be exported over the network? A: No. It is bound to localhost, not the standard listen address "0.0.0.0". Q: What about third-party sites manipulating the HTTP server by way of AJAX, redirection, or forms? A: For AJAX, I added an Access-Control-Allow-Origin header that modern browsers can use to accept or deny connections. For redirection, I am making all the handlers use POST instead of GET. For forms, I'm going to use a simple CSRF technique: you POST to a URL and get a token back that has to be used in the next POST request. I don't think IFRAMES can make POST requests, nor can web sites scrape content from it that's from an external domain. Q: What about a user that has access on the current machine manipulating another user's Shell session? A: I'm going to scrape "netstat" or "/proc/net/tcp" on every connection and make sure that the UID that's making the HTTP connecting matches the UID of the current user's Shell session. Q: What about multi-user sessions? A: I will probably have a list of ports about 10-long, trying one after the other until the first one lets me in, as described above. == Convenience == Q: My localhost/127.0.0.1 is behind a proxy server. What can I do? A: Right now? Don't do that or... Q: What happens when I'm offline and want to disable/enable extensions? A: Well, for those cases, I'll probably have an extremely bare-boned UI that allows people to disable/enable extensions. == Code Quality == Q: Eww... fixed ports are ugly. A: Not really... most services usually only live on one fixed port: HTTP is on 80, FTP is on 21, SSH is on port 23. Q: Why not use an in-process server to Shell or libsoup? A: The current Python implementation is a toy, and I'll probably write a server in libsoup. It may be in-process with GNOME Shell, written in GJS. I'm not sure yet. == At this point, I feel everything can possibly be said has been said. On Thu, Jun 23, 2011 at 12:26 PM, Milan Bouchet-Valat <nalimi...@club.fr> wrote: > Le jeudi 23 juin 2011 à 22:00 +1200, John Stowers a écrit : >> On Thu, 2011-06-23 at 11:48 +0200, ecyrbe wrote: >> > thank you john for the bits of history of the design. >> > i do know about server programming, as in fact it's my job to make >> > high load servers in c++. >> > i also understand the design better and the solution you try to >> > provide. >> > >> > as i said. you can make the server lightweight inside the shell, i >> > don't think people would complain as this would make it a lighter >> > solution than a separate daemon. >> > The problem with a separate daemon, is that you end up using a process >> > to do nothing 99% of the time. integrating it in the shell would make >> > it : >> > - leightweight -> you only add a listening port to gnome-shell. >> > - integrated -> you don't need to add a dbus api to control extension >> > enabling/disabling >> > - easy to implement -> you only have to use libsoup asynchronously, no >> > threading use >> > - no memory overhead -> it's integrated in the shell , you don't have >> > to allocate a new stack for it >> > >> > so, why not integrate it? why would people complain ? >> >> Cool. As an engineer you probably also understand that one does not >> always start with the perfect implementation. >> >> Pragmatically the separate process HTTP server is not bad for a first >> go. >> >> I'm still not convinced a process that is sleeping 99% is a big deal. It >> should be swapped out and take no resources. > On the plus side of the out-process approach, if we switch to systemd to > handle the whole user session, the HTTP daemon will merely register the > port, and would never be started until actually used. So, if you want to > discuss theoretical details of a few kB of RAM, you also need to > consider this possibility. ;-) > > > Cheers > > > _______________________________________________ > gnome-shell-list mailing list > gnome-shell-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > -- Jasper _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
