Repository navigation
Security considerations #22
Description
Activity
In a previous incarnation of sort of the same thing (but windows only), it was possible to hook into chrome, register a scheme and have the handler take the request and directly invoke it against the pipeline.
https://github.com/eVisionSoftware/Harley/blob/master/src/Harley.UI/MainWindow.xaml.cs#L23
https://github.com/eVisionSoftware/Harley/blob/master/src/Harley.UI/Owin/OwinSchemeHandlerFactory.cs#L44I'd be really surprised if there wasn't an equivalent hook in Electron.
The hard part is probably hosting the .net code / clr in the same process. Definitely done elsewhere, but beyond my knowledge at this point.
Wondering if edge.js has anything useful to lift?
Reacted by andi0b- Reacted by Robert Muehsig and Jared Thirsk
Nice one - I guess currently our priorities would be to work on some basics, like easier debugging support or actual better build support (Icons for the produced app etc.), but I'm really interested in doing this 👍 (or if you have some sparetime - just sent a PR 😃 )
My xcore plugin for nodejs can smoothly call any netstandard assembly from nodejs (even async stuff) [in-proc of course] without having to do nothing for the interop (I do generate the required code on the fly) and allows to call almost any method/property/indexer/event/ctor.
Could this be of any help?Sure - do you have a GitHub Repo for your code?
The repo just contains the user guide and a couple of videos explaining how it works, but no sources yet.
https://github.com/raffaeler/xcoreI published the plugin here:
https://www.npmjs.com/xcorenodeThere are few things that are worth to say:
- I am going to change the C++ part heavily in order to adopt N-API which is the nodejs API which should not require to recompile the plugin for each nodejs version
- I could use it from the standard Electron but in certain cases Electron crashes. Looking with windbg the crash, it does not depend on my plugin but noone (in chat or on github) from Electron helped me to understand the issue.
- I am also improving the perf in the netcore side of the plugin
- Part of the plugin is already x-plat (like for example loading coreclr) but I still have to adjust few other things to make it entirely work on linux.
If you have other questions, please let me know
@raffaeler Is XCore/XCoreNode similar to Edge.js but works with .NET Core?
I like to say that is more than that.
Edge.JS impose a fixed signature for the method to be called while xcorenode leave the .net developer free to shape the class at her will. Also, Edge.JS limit to methods while I allow ctos/props/methods/events, even with overloads (that were pretty difficult to implement).
The setup is also simpler. When I initially tried to use Edge.js, I had several troubles.
Instead I opted for a "self-contained deployment" so that all the required .net binaries are available and part of the plugin.
You can take a look to the npm package javascript examples to see the supported features.Anyway, Edge.js is more mature and targets more than just .net interop, therefore please don't take my words as a critic towards Edge.js.
Reacted by Robert Muehsig, Andrew McClenaghan and Damian HickeyI like the idea of trying to internalize the webserver but it would be great to maintain the option of exposing the webserver when desired (I'm working on a project where I absolutely do want the webserver reachable from other processes running on the machine)
Reacted by Gregor BiswangerI have an idea with an own web proxy, which can not listen with Fiddler or an other HTTP Debugger.
The next idea is to allow only requests from electrons chromium browser.. It's not the best and I need help to create the web proxy with .net core..
We can give an additional option to deactivate some new security parts...
Reacted by Meteorsnows@GregorBiswanger I don't get your goal.
If you want to disable people sniffing the page, it's useless. I wrote a driver that can capture even localhost (which is "short-circuited" and is not processed from the whole network stack).
From a security perspective, once you are admin of the local machine, the game is over.Reacted by Gregor Biswanger and GOVINDA ALWANI@raffaeler Yes, that is true. But every Electron application and local desktop application is not secure.. (reverse engineering etc.).. I think this steps are important to have a little better security.. protection of kiddy crackers :)
That is only an idea.. at the end the community should decide too..
I'm happy about other ideas too...
5 remaining items
Definitely need the IPC. When I first started looking at all this, I figured wtf is this IPC thing, I want "real" tech like SignalR, but then as I better understood what what going on I realized that IPC really is the right way to communicate between the two processes because it's a low-level direct pipe that's not exposed to the rest of the OS.
The way you have IPC and hosting of dot net integrated into Electron.NET is the magic that's the key to all this wonderful goodness.
Reacted by Robert MuehsigWild idea to skip the ASP.NET stuff completly (at least for the "builded" app) : It would be possible to xcopy the wwwroot files to the electron dir, which will be packed, then we just need to boot up a .net core console application with the IPC stuff for the "backend".
Development/debugging might be "harder", but could work.
I'm pretty sure that Electron already supports hot reloading of the HTML/JS, so if you tweak the source JS files it would automatically do the transpiling/webpacking/loading/refreshing etc on the fly as you type in your editor. It's pretty slick stuff.
<- Technically the "it" that I referred to about would be webpack that's watching the filesystem and regenerating the code and such (I have all that running now in my boilerplate, the /wwwroot/bundle.js files will auto regenerate as you change the source files, but my HTML isn't configured yet to hot-load the updated bundle.js files (I think that's a pretty straight forward thing to do on the npm/HTML side, I just haven't gotten to it yet)
Mhhh... so you suggest we should just host the IPC stuff inside the actual .NET Core process?
I'm WAY less knowledgable about the dotnet core internals than you guys are but I think that's what I'm suggesting. Then you'd still be able to host ASPNET if you wanted to but it wouldn't be a required part of the process. You'd just need some way to tell Electron to host the files that are currently thought of as the /wwwroot contents if you were to make ASPNET optional.
@konding all I know is the "IPC" terminology comes from how atom and Electron talk about their code. I'm not sure if the ElectronNET bits are implemented the same way as the base Electron IPC but @robertmuehsig or @GregorBiswanger probably know
Mhh... the communication path is described here. Our Electron.NET talks via this Socket to the Electron stuff.
I'm not sure what the definition of IPC is, but we use http as the channel. At work we are using named pipes to do IPC, but we just run on Windows. What is your definition of IPC @konding ?
FYI I could solve the issues of my plugin with Electron. It was not a real bug, but both me and Electron used a "slot" so each of us was overwriting the other.
Anyway, I could successfully run C# code inside the renderer process. I still have no public releases.
BTW, if anyone of you is at the next mvp summit, I will be there and we can chat about it.@raffaeler Then we shall meet at the summit :) @GregorBiswanger
You can bet! :) My handle here is the same on twitter.
I have added the build parameter to /p:PublishSingleFile true in my recent PR.
I have a version of blazor webassembly, with host running in Electron.NET, bundled as single .exe file.The only code exposed is .wasm file, so disassembly is not as easy as dropping DLL's into ILSpy or DotNetPeek anymore.
Also the app doesn't ship with any dll's this way. just a single .exeIf some people are strictly concerned about security, here's something I did for my project: domialex/Sidekick@6a9f7bf
Important parts are the
await browserWindow.WebContents.Session.Cookies.SetAsync(electronCookieProtection.Cookie);and theElectronCookieProtectionMiddleware.I just added a cookie with a Guid generated on startup to the BrowserWindow, then a middleware that verifies it on every request. Works perfectly.
Reacted by cosmo0, Mark Lopez, semanticStu and Pierre Arnaud
Twitter discussion - currently we launch a plain webserver on localhost. Maybe we could avoid to launch a "real" webserver at all, see here:
https://twitter.com/robert0muehsig/status/924741177525587968