9 ms·

I've been using vercel/pkg with great success, in order to achieve a similar target and package a whole application into a standalone executable: https://githu

• galaxyLogic 6y ago
  I'm using vercel/pkg as well. I have a Node.js server which generates HTML and opens a browser on Windows which then asks the server for that html at 127.0.0.1. So browser will be my GUI and Node.js packaged with vercel/pkg my back-end. It is more flexible than say Electron because GUI can be anything I want it to be. My concern is only will users accept a local server running on their desktop. I've tried to configure the executable so that the server accepts connections only from the same host as where the http-requests are coming from. I assume the same situation would exist with Denon, if you build a product with it and want to use the browser as your front-end. Are users OK with a server running on their PC?
  • Couto 6y ago
    This reminds me of the server that Zoom used to have. Accepting connections only from 127.0.0.1, alone, isn't enough, since any request from the browser would match that IP, even if the request was being made through a XSS attack. I'm sure someone with more knowledge in security would better chime in.
    • jjnoakes 6y ago
      What I do is generate a random token, pass it to the browser I spawn, and only accept requests that include the token.
      • galaxyLogic 6y ago
        That's a good trick. Thanks for the tip.
      • cjonas 6y ago
        Wouldn't proper CORS be enough? I guess you would have to avoid putting any sensitive data in GET requests
        • z3t4 6y ago
          One problem is that we developers are lazy and use Access-Control-Allow-Origin: * (wild star) instead of actual hostname. (eg. allowing all origins to access the backend) No modern browser allows access to localhost without that header. But it's still possible to forge a request using curl or whatever to bypass CORS. So as the parent post suggest - use a token of some sort. I also recommend using a strict Content-Security-Policy to stop X-site injection attacks. (eg someone adding an image to your page/app with src="/api/cmd=rm -rf /"
        • feanaro 6y ago
          No, because CORS can only restrict which origins (scheme, domain, port combinations) are able to access the site's data. But you're not even connecting from a web origin but from localhost and you're trying to defend from all access except by your frontends. For this, you need a shared secret between the server and the frontend. A further limitation of CORS is that certain requests are allowed even if they are not from an allowed origin. To conclude, you definitely need a secret.
          • chrisweekly 6y ago
            I'm so fuzzy on the details but isn't this what client certs are for?
            • feanaro 6y ago
              You could accomplish this with client certs too, sure. A random secret is a simpler solution in many ways and accomplishes the same goal, though.
  • j1elo 6y ago
    > My concern is only will users accept a local server running on their desktop I would say that users don't mind. They want a working application, that does what it promises, and is dependable. Things like having an underlying server is just an implementation detail, nobody really cares (talking about the big public here, not the more technical users of HN who might have a say about the technology choices, but are overall a very small portion of potential users) That doesn't mean the implementation should be sloppy, though! Make sure to iron out all those security concerns regarding 127.0.0.1, because it could cause a data breach or some other severe damage. Other than that, just aim to provide the best user experience.
    • galaxyLogic 6y ago
      Right. One additional complication might be that some web-tech in the browser may require https, which would bring its own complications with security certificates.
      • ludwigvan 6y ago
        PSA: If you have an https web site that needs to talk to your server in localhost, that localhost server does not have to run https since localhost is considered potentially trustworthy. It will not trigger the mixed content errors (for Chrome and Firefox – Safari does not do this for now, but it is in the works: https://bugs.webkit.org/show_bug.cgi?id=171934 https://bugs.webkit.org/show_bug.cgi?id=171934 ) I have seen some companies do the following too: They embed a snake oil certificate and instruct people to disable web security, don't do this. Some other companies do something like purchase a foolocal.com https certificate (spotify and dropbox do this I believe), but that certificate might be revoked afaik. As to CORS, you need to check that the incoming request comes from your own remote machine, otherwise if you enable cors for all, other sites can scan and get your user's data (ebay was recently doing this, scanning ports: see https://blog.nem.ec/2020/05/24/ebay-port-scanning/ https://blog.nem.ec/2020/05/24/ebay-port-scanning/ )
  • sixbrx 6y ago
    Do you have any trouble with the users being prompted by the Windows firewall to allow the server to listen on localhost? I like this way of doing things but I've had propmts like that for my own dev tools and I think that would put off my users.
    • dvt 6y ago
      Anecdotal, but I maintain a mildly popular Spotify player (https://github.com/dvx/lofi https://github.com/dvx/lofi) which needs a similar flow for OAuth authentication. I've never had an issue created or complaint about the Windows Firewall popup.
      • ROARosen 6y ago
        Nice player BTW never heard of it!
    • galaxyLogic 6y ago
      I can see that could be an issue. I guess one solution is to make sure users understand that that is going to happen. These days everybody is used to their smartphone asking things like "Do you want to allow App-X to use your microphone" etc.
    • ludwigvan 6y ago
      Interesting. Are you sure the firewall prompt comes when the server is listening on 127.0.0.1 as opposed to 0.0.0.0?
      • sixbrx 6y ago
        I'm not actually sure in which cases the prompt happens these days - I meant that to be part of what I was asking but didn't word it very well. Hopefully listening on 127.* doesn't trigger it!
  • yboris 6y ago
    > It is more flexible than say Electron because GUI can be anything I want it to be. Feels like one of us is misunderstanding something. Electron lets you run any web technology - so when users open your app, they are greeted with whatever you can show on a webpage. You can also have Electron run in the background as a server if that's something you're into ;)
    • sciolistse 6y ago
      I believe the idea is if you wanted a client built with C# Winforms, wxWidgets, JS+HTML or anything else they could all run against the same backend server.. So it'd be more flexible than Electron in that you wouldn't need to use web technology at all, if you don't want to.
      • galaxyLogic 6y ago
        Right. Also each Electron app "comes with a copy of two large software frameworks, Node.js and Chromium" ( https://medium.com/dailyjs/put-your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297 https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w... ) Whereas if you build starting from Node.js (or Deno I assume) you can skip the Chromium part. Instead of packaging Chromium with your app you assume that users have a browser and can use that to talk to your app. The benefit of using Node.js is you don't have to use a different language for the backend. It helps. BTW. "Electrino" in the linked-to article seems interesting too.
        • feanaro 6y ago
          The additional benefit of this approach is that you can then build your application such that it works with all standards-compatible browsers, such as Firefox.
          • yboris 6y ago
            That's not a benefit - that's a down-side. When writing a front-end for Electron, you only worry about 1 browser and you have a guarantee that it will work the same way across every OS. If you have to write a front end (website) that works with more browsers, you have to put in moro work.
  • breatheoften 6y ago
    > My concern is only will users accept a local server running on their desktop. This sounds pretty cool -- is there a way for the deno runtime to restrict the server process to only be able to generate the legal types of http traffic that a browser could generate if allowed to open a connection to a specific url (or set of urls)? If so i'd feel more comfortable about running the embedded server -- ideally the security risk of running the server would be closer to the risk when running an embedded set of daemon browser tabs -- rather than the risk when exposing all the unfettered power of a unix process ...
  • ausjke 6y ago
    in this case why not just use go-binary as the backend? go is natively designed to be single executable and you don't need any package tools, and it does everything node.js can do on your OS while using your browser as a GUI frontend.
    • aabbcc1241 6y ago
      Except you'll have to develop with another ecosystem of packages and cannot do generic programming "natively".
  • Mulpze15 6y ago
    I am trying to do this too. But I would like to make it work on MacOS as well. The problem there is Safari does not let you connect to localhost over http. So if Safari is the preferred browser of the user, you need to convince them to change, which is hard. Or is there à better way there?
    • z3t4 6y ago
      I can connect to localhost on Safari Version 14.0.1 Make sure you also load index.htm from the same host! (localhost) so you need a little web server in your app that serves that file. One problem is however that there is no easy way to get Safari to run in chromeless/app mode (without browser/url bar etc), which you can do in most other browsers using --app=url flag
      • Mulpze15 6y ago
        Thank you, I will try. I was actually trying to mix web app (https:// https:// mydomain.com) and connecting to localhost. And yes, a localhost URL in the bar looks ugly... Trade-offs...
    • ludwigvan 6y ago
      See https://bugs.webkit.org/show_bug.cgi?id=171934 https://bugs.webkit.org/show_bug.cgi?id=171934 I hope they'll fix it soon.
      • Mulpze15 6y ago
        I may misunderstand the thread, but it looks to me like they don't want to fix it, even though it is the spec, and other browsers do follow it.
  • egeozcan 6y ago
    I did the same but used a server coded in go[0], I don't think it's a security problem as long as you take the standard security measures that apply to any web server. Mine is something that just scratches my itch so I explicitly enabled cors (if a malicious website can guess the endpoint, it's possible to get my stupid dev logs as JSON during the times this logger is running). [0]: https://github.com/egeozcan/json-tail https://github.com/egeozcan/json-tail
• cocktailpeanuts 6y ago
  I'm not very familiar with Deno but I wonder how deno compile compares to pkg when it comes to native modules. One of my gripes with PKG (and all other node.js packaging tools) has been that it's a pain in the ass to package when your dependency includes a native module, for example SQLite. Since Deno has a different architecture and works in different ways, thought I would ask just in case there's a solution for this on Deno, that would be great.
  • j1elo 6y ago
    Yes, packaging a binary dependency can be problematic. I guess it depends on how easy the library puts it to import the binary in a compatible way (with the mechanisms that are expected by pkg)
  • miohtama 6y ago
    WebAssembly fixes this.
    • zubairq 6y ago
      Not really as the WASM version of Sqlite is memory only and cannot write to disk. Please feel free to correct me if this has changed though
      • tracker1 6y ago
        Nope... the wasm fs adapters don't allow the flexibility needed to really operate correctly. It might be best to try alternatives like wrappers around leveldb as a baseline, which of course isn't sql and has its' own drawbacks.
        • kevin_thibedeau 6y ago
          SQLite still has a workaround for locking on Win95. That could be adapted for wasm. https://github.com/sqlite/sqlite/blob/610f11de25993960ff616edde0f5dc47d1c0b56e/src/os.h#L94 https://github.com/sqlite/sqlite/blob/610f11de25993960ff616e...
• 205g0 6y ago
  What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience but encourage the community to compete and complement. Integrating build systems is good for beginners who struggle with them but for the rest? IDK. Or in other words, Deno wants to be more than just an opinionated node-Typescript-distribution nobody cares about but then they need to create this ecosystem and focus on the core (what's their core and value add other than repackaging node and TS would be the next discussion). With integrating the build step they do the exact opposite, they shut-down an ecosystem before it can even start. There's a night and day difference between good and bad build systems and only competition and a rich ecosystem can bring up the best solutions. FWIW, there're tons of ways to compile TS, every with different trade-offs and it's good that we have these options.
  • oorza 6y ago
    Why anyone would look at the litany of mistakes that is npm and Node, then look at Deno and all of the same developers learning nothing except how to implement its "hurr durr URL loading code is cool" approach to security and think "this a good idea" is beyond me. I appreciate Deno because I can ask job interview candidates what their thoughts are about it, and when candidates for senior positions don't point out any of the billion obvious reasons it's a stupid project for stupid people, it saves me a ton of time. Otherwise, it's a waste of time and effort, and all you have to do to convince yourself of that is look at the contribution history of the most prominent contributors on github. I have never, not once, in my life as a developer wanted a project to die so badly.
    • cjonas 6y ago
      With an attitude like yours, I think it's the candidates who saved a ton of time...
    • mssundaram 6y ago