8 ms·

An underused option is to include a local HTTP server in your native app and open it in the user's default browser. This avoids some of the resource consumption

An underused option is to include a local HTTP server in your native app and open it in the user's default browser. This avoids some of the resource consumption and security issues that make Electron bad, but still lets you integrate native code with a web UI. I wrote a little framework for this: https://github.com/jdarpinian/web-ui-skeleton https://github.com/jdarpinian/web-ui-skeleton

krapp 6y ago
This is how Electron style apps should work, instead of wrapping an entire browser instance around each app to maintain the illusion of it not being at all web based.
- wffurr 6y ago
  They are called PWAs
  - remram 6y ago
    PWA refers to the client-side app only. They are not related.
    - wffurr 6y ago
      How do you figure? You can locally host or package a PWA same as Electron. Chrome at least is closing the gap in capabilities too.
      - deleted 6y ago
        [deleted]
- innocenat 6y ago
  No. I want to be able to Ctrl-S and it save the changes I made to the file (for example, but this is the most annoying thing for me) That doesn't work with actual browser.
  - modeless 6y ago
    Yes it does. Just preventDefault() the keyDown event.
    - Macha 6y ago
      And now you start a download and the modified file goes into the User's download folder as file(n).whatever instead of wherever they opened it from.
      - modeless 6y ago
        No, remember that you have a local server running native code. The server can handle writing the file to any path you want.
        innocenat 6y ago
        But if you do that, you also have to handle file opening from the native local server side too (because browser file browser will not tell you actual file path). And of course, that dialog won't be a modal of the browser. This is getting weird very quickly (not to mention that Ctrl-S in browser windows saving file without confirmation is a UX I wouldn't want to use)
        modeless 6y ago
        > And of course, that dialog won't be a modal of the browser. There are several decent options. You could build a modal that displays a view of the file system sourced from the server. Or you could pop a real native file dialog from the server, and I'm betting it's possible to either make it a real modal of the browser window or do a good enough simulation depending on platform. Or in the future you could use the native file system API that is currently in origin trial. I submit that this is not weirder than most cross-platform UI toolkits that implement their own whacky replacements for the native file dialogs.
donatj 6y ago
Is there a good way of doing SSL with this that doesn’t require hacking self signed certs into the users browser? A lot of newer web APIs are requiring SSL.
- yorwba 6y ago
  You can access those APIs using SSL from the server, which then relays the results to the client.
- J-Kuhn 6y ago
  Most modern browsers should consider http://127.0.0.1/ http://127.0.0.1/ or http:// http://[::1]/ as trustworthy. See https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy
  - kodablah 6y ago
    In my experience, it's http://localhost http://localhost that is considered secure, but not http://127.0.0.1 http://127.0.0.1. This may have changed since I last checked.
- modeless 6y ago
  I believe that Chrome treats all localhost connections as secure now. Not sure about other browsers.
takluyver 6y ago
I've worked on some applications like this, and it works pretty well. But be aware that a port on localhost is accessible to any local user - depending on the application you may need to prevent other users accessing it. Running inside a real browser also limits the keyboard shortcuts you can use, because you don't want to clash with the browser's own shortcuts.
- amaccuish 6y ago
  Weirdly, Windows makes it easier to do this securely in that you can do NTLM authentication to authenticate local users (maybe MacOS as well, I believe internally it runs its own Kerberos server for the local machine).
  - lukevp 6y ago
    AFAIK you can only do this if you disable the local loopback check that prevents windows auth from passing credentials to local host webservers.
    - amaccuish 6y ago
      Why did they put that in in the first place? To stop cracking of local passwords?
- stragies 6y ago
  Can't this concern be easily alleviated by the backend requiring credentials, and sending them along from the frontend? Getting around this as an attacker means already possessing enough rights to not need sniffing the traffic to the backend. Or is there more required?
  - takluyver 6y ago
    It can, but getting the credentials to the browser & storing them there isn't entirely simple. If you launch a browser process to a URL containing a token, an unprivileged local attacker can see it in the command line arguments (at least on some platforms) and copy it. That can be mitigated by launching the browser with a file:// URL which uses an HTML meta redirect to give the browser the token. The obvious way to keep the browser authenticated is a session cookie. But cookies are shared between all ports on a domain, so a local attacker who tricks you into visiting another localhost service in the same browser can steal the cookie. localStorage doesn't have that issue, but it's not so convenient for authenticating requests.
yonixw 6y ago
But if you want to interact with local file-system (like open dialog) it start to get complicated.
zelly 6y ago
> security issues that make Electron bad Exposing a HTTP port with application state is a million times worse for security
- modeless 6y ago
  The server binds to the loopback interface, so it's not exposed to the network at all. Then as long as you use CSRF protection and an appropriate Content Security Policy it is safe.

krapp 6y ago

This is how Electron style apps should work, instead of wrapping an entire browser instance around each app to maintain the illusion of it not being at all web based.

wffurr 6y ago
They are called PWAs
- remram 6y ago
  PWA refers to the client-side app only. They are not related.
  - wffurr 6y ago
    How do you figure? You can locally host or package a PWA same as Electron. Chrome at least is closing the gap in capabilities too.
    - deleted 6y ago
      [deleted]
innocenat 6y ago
No. I want to be able to Ctrl-S and it save the changes I made to the file (for example, but this is the most annoying thing for me) That doesn't work with actual browser.
- modeless 6y ago
  Yes it does. Just preventDefault() the keyDown event.
  - Macha 6y ago
    And now you start a download and the modified file goes into the User's download folder as file(n).whatever instead of wherever they opened it from.
    - modeless 6y ago
      No, remember that you have a local server running native code. The server can handle writing the file to any path you want.
      - innocenat 6y ago
        But if you do that, you also have to handle file opening from the native local server side too (because browser file browser will not tell you actual file path). And of course, that dialog won't be a modal of the browser. This is getting weird very quickly (not to mention that Ctrl-S in browser windows saving file without confirmation is a UX I wouldn't want to use)
        modeless 6y ago
        > And of course, that dialog won't be a modal of the browser. There are several decent options. You could build a modal that displays a view of the file system sourced from the server. Or you could pop a real native file dialog from the server, and I'm betting it's possible to either make it a real modal of the browser window or do a good enough simulation depending on platform. Or in the future you could use the native file system API that is currently in origin trial. I submit that this is not weirder than most cross-platform UI toolkits that implement their own whacky replacements for the native file dialogs.

donatj 6y ago

Is there a good way of doing SSL with this that doesn’t require hacking self signed certs into the users browser? A lot of newer web APIs are requiring SSL.

yorwba 6y ago
You can access those APIs using SSL from the server, which then relays the results to the client.
J-Kuhn 6y ago
Most modern browsers should consider http://127.0.0.1/ http://127.0.0.1/ or http:// http://[::1]/ as trustworthy. See https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy
- kodablah 6y ago
  In my experience, it's http://localhost http://localhost that is considered secure, but not http://127.0.0.1 http://127.0.0.1. This may have changed since I last checked.
modeless 6y ago
I believe that Chrome treats all localhost connections as secure now. Not sure about other browsers.

takluyver 6y ago

I've worked on some applications like this, and it works pretty well. But be aware that a port on localhost is accessible to any local user - depending on the application you may need to prevent other users accessing it. Running inside a real browser also limits the keyboard shortcuts you can use, because you don't want to clash with the browser's own shortcuts.

amaccuish 6y ago
Weirdly, Windows makes it easier to do this securely in that you can do NTLM authentication to authenticate local users (maybe MacOS as well, I believe internally it runs its own Kerberos server for the local machine).
- lukevp 6y ago
  AFAIK you can only do this if you disable the local loopback check that prevents windows auth from passing credentials to local host webservers.
  - amaccuish 6y ago
    Why did they put that in in the first place? To stop cracking of local passwords?
stragies 6y ago
Can't this concern be easily alleviated by the backend requiring credentials, and sending them along from the frontend? Getting around this as an attacker means already possessing enough rights to not need sniffing the traffic to the backend. Or is there more required?
- takluyver 6y ago
  It can, but getting the credentials to the browser & storing them there isn't entirely simple. If you launch a browser process to a URL containing a token, an unprivileged local attacker can see it in the command line arguments (at least on some platforms) and copy it. That can be mitigated by launching the browser with a file:// URL which uses an HTML meta redirect to give the browser the token. The obvious way to keep the browser authenticated is a session cookie. But cookies are shared between all ports on a domain, so a local attacker who tricks you into visiting another localhost service in the same browser can steal the cookie. localStorage doesn't have that issue, but it's not so convenient for authenticating requests.

yonixw 6y ago

But if you want to interact with local file-system (like open dialog) it start to get complicated.

zelly 6y ago

> security issues that make Electron bad Exposing a HTTP port with application state is a million times worse for security

modeless 6y ago
The server binds to the loopback interface, so it's not exposed to the network at all. Then as long as you use CSRF protection and an appropriate Content Security Policy it is safe.