Automatic Port Selection and Secured Communication#1038
Automatic Port Selection and Secured Communication#1038FlorianRappl wants to merge 7 commits intodevelopfrom
Conversation
…into feature/socket-enhancements
pr-comment: Run #62
🎉 All tests passed!Github Test Reporter by CTRF 💚 🔄 This comment has been updated |
|
Should we move this forward @softworkz ? |
|
Sorry, haven't come to this yet. Why is there a merge conflict? |
There is none. There was initially one as planned due to the splitting. |
|
|
Shows different for me: 
Also: 
Furthermore: |
softworkz
left a comment
softworkz
left a comment
There was a problem hiding this comment.
I'm very sorry for responding so late!
src/ElectronNET.API/Runtime/Services/ElectronProcess/ElectronProcessActive.cs
Show resolved
Hide resolved
src/ElectronNET.API/Runtime/Services/ElectronProcess/ElectronProcessActive.cs
Show resolved
Hide resolved
| var tcs = new TaskCompletionSource(); | ||
|
|
||
| void Read_SocketIO_Parameters(object sender, string line) | ||
| { | ||
| await Task.Delay(10.ms()).ConfigureAwait(false); | ||
| // Look for "Electron Socket: listening on port %s at ..." |
There was a problem hiding this comment.
There should be a path completely without reading the process output.
(without auth token)
There was a problem hiding this comment.
I would not do that. It's less secure and just more complicated. Let's keep it to the point.
There was a problem hiding this comment.
I do not want to have that in our application that dotnet is relying on the console output of Electron.
There was a problem hiding this comment.
I have nothing against making the auth token mandatory, but it can be provided by the dotnet side as cli param, so it doesn't need to be read it from the console output. (that's no more and no less secure)
There was a problem hiding this comment.
Theoretically possible, but that's another branch / logic that we would need to take care of. So I'd opt out of that.
There was a problem hiding this comment.
Was just a thought. My only actual concern is the console parsing. That's admittedly a rather egoistic concern. I do not mean to say that parsing CLI output is generally wrong or bad, it's about the specific context of our app: Linux is a world of 1001 surprises, often bad surprises and I don't want to employ anything which has potential for causing bad surprises - that's why I would like to retain a path where this doesn't happen.
Thanks
There was a problem hiding this comment.
Yeah can relate to that... My suggestion would be to have it merged / out in a preview version and test it extensively. If that does not hold / has weak points then I think a different approach must be anyway found (because I would still insist that a single flow is better than multiple - but that single flow has to work in all cases).
There was a problem hiding this comment.
The problem is this: as soon as this is merged, there is no more point for me to submit any fixes and updates, because I cannot use the packages anymore.
Beyond my own usage, introducing something new in a way that it's optional, is generally advantageous:
- Nobody's story will be hard broken or blocked
- It's useful for differential diagnosis when issues are reported, to determine whether it's by the new code or due to other reasons
- It would make me very happy 😉
Co-authored-by: softworkz <4985349+softworkz@users.noreply.github.com>
2 participants
Follow up for #1021 - should be reviewed / merged after #1037.
Introduces an authentication token to be used in the communication between Node.js (Electron) and .NET. The same token can be used to also guard an ASP.NET Core server - allowing only access from within the boundaries of the running application.
The port is now OS-selected - guaranteeing a free accessible port. No tools to find free ports are necessary.
The owning part (e.g., Node.js for the WebSocket connection to control the Electron application) also owns / opens the port - independent of the used startup mode.