-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
electrify and meteor deploy #24
Comments
Hello @srtucker22! Thanks for the kind words. Not a noob question, but a very common requested feature. It's currently not supported but there's a workaround to get this to work, and also another approach using another project. The ability to package a Please interact if you have something to add to the table. 🍻 Supporting Client Version onlySupporting a Would be cool to know how MDG has handled this kind of thing. Anyone? Electron integration & Security NotesOne may also want to execute Electron commands from Meteor's Is it common for a remote backend to deliver arbitrary code to clients that can execute local (and potentially malicious) commands on user's machine? |
Thanks for the awesome response, and a solid writeup at that. Currently investigating something similar to meteor-electron-client for my immediate needs. I've never built an electron app before -- as a meteor nut, I was just expecting something as simple as But I'm totally with you. I think something of a combination of meteor-electron-client and electrify is what the community needs to get to something like I'll stay tuned to this thread, and update with any learnings once I go through the process. Cheers! 🍻 |
@arboleya, How I thought a client-only would work (which is the intended use case for Meteor, a full-stack App) is that the webview would open up the actual webpage deployed online (e.g. myapp.meteor.com) - so you don't have to worry about DDP issues, Electron behaves as a regular browser. But additional wrappers would allow the client code to interact with the user's machine (e.g. fullscreen) and provide a consistent cross-platform browser. This has the added advantage of reverting back to Meteor's security paradigms. In fact, this is how most Chrome Apps I have seen work (just wrappers for an online source / webpage with local code to access specific user machine needs). What do you think @arboleya, wouldn't this approach make life easier? |
Hi @ramezrafla, I see this as a first implementation, more simplistic and straight to the point. But I wonder what are the benefits of caching files locally, with an auto-update routine, much like Meteor did with They did because it was a good design, or they did it because this was the only way to pack mobile apps? I don't know if one can get an "empty" app, that launches remote a website inside of it, out in the AppStore or PlayStore. Do you know if it's possible? While this can be a good reason they went down this way, I think this point should be further discussed with more research around the |
Hi @arboleya
So for the sake of speed of deployment, I am ok with a dumb client. Implementing custom DDP protocol for desktop is a headache and is unlikely to be needed universally (most Meteor Apps are fine running in the browser). |
@ramezrafla I agree about a dumb client before anything else to speed things up. However I see no reason for a "custom DDP" for desktop. The only pending thing will be having client files locally, self-updating at each new hot-code push. But it can wait. I think we have a first draft, I'll find the time to test this. |
i don't think security concerns should be considered at this very moment, the whole internet was running IE6 and Netspace 4 for "decades" and nobody died. No to say, once you running an executable file on your machine, you are aware some weird things might be happening anyway ?? great work on the package, btw |
@hems Consider a man-in-the-middle attack, someone could deliver a clone app with their code inside it to your Electron window, and easily gain full access to your file system, keyboard, pressed keys, clipboard, screen, and everything else. This doesn't depends on trust between you and the app owner. |
Absolutely, it's up to the developer to make sure the code is secure, and that it is available in a trusted manner. A cloned app that is similar to yours is likely the user's fault (they should download from your site). Insecure code, is the dev's fault. Chrome apps are typically like this. A local sandbox accesses the local environment and it communicates securely with the app's back end online. |
@arboleya a man-in-the-middle attack could also delivery a totally different binary to you even when you download Skype, Chome, or Tor Browser. ps: I'm not saying it's not a valid concern (( : |
Security is a valid concern, indeed. I'm also not the only one concerned, but it looks like there are some things one can do to deal with this insecurity. Just need to dig a little deeper. |
Hey there,
This is an awesome project.
Maybe a total noob question here, but is there a nice way to connect the electrify version my app to a deployed app (e.g. myapp.meteor.com)?
Was thinking about using this to make a desktop version of an open source video chatroom I've thrown together. Electrify version of the app works like a charm locally, but I'd want to be able to connect peers on different computers obviously :)
Thanks for your help!
The text was updated successfully, but these errors were encountered: