|
is there a reason you don't look for, and study, recent articles like this: [^]
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I thank you for the reply.
Does this article give insight into how to secure the data passing over a named pipe so that only my application can read it?
I can say that the main reason I didn't look for that article is that it's not relevant to my question.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Message Closed
modified 4-Jan-23 4:59am.
|
|
|
|
|
I never said any of that. If this question is a waste of your time, then don't reply.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I assume that you will be using streams ... you could use the CryptoStream Class (System.Security.Cryptography) | Microsoft Learn[^] to encrypt & decrypt. If you google, you will find examples on how to do it if the MS examples are not enough.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Ahh! Thank you Graeme. That's the kind of pointer/tip I was looking for.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Cryptography secures what's "in the pipe"; it doesn't "secure the pipe". You're back to Access Control.
Named Pipe Security and Access Rights - Win32 apps | Microsoft Learn
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Very good point. Thank you. I am more interested in securing what's in the pipe. I want it so that even if someone can connect to the pipe, they won't be able to make sense of what's going back and forth.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
jschell wrote: Thread here suggests that more might be needed.
SSL is a CryptoStream.
What you don't have is authentication.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Hmmm,
You haven't really given enough information but I think you are wanting to:
- Have an application read/write over a named pipe.
- Prevent the application user from accessing the named pipe. (Essentially securing or isolating the information/pipe from the user)
If I were asked to do this I would use a DLL Surrogate and have the Custom Surrogate process open and manage the named pipe. This would allow you to have some security separation between the application users and surrogate process.
|
|
|
|
|
Your guess is spot on.
I'm glad you responded. Writing a native COM server might be slightly beyond my knowledge scope, but it probably depends upon exactly how secure I need the pipe's contents to be.
The information would be proprietary in nature, but it wouldn't be sensitive like personal user data.
I will consider this as a possibility. Thanks.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard,
It's much simpler than you can imagine. I can't think of any other way to accomplish your goal. What you are trying to achieve is less than 12 hours of work with a DLL surrogate. I can't remember off the top of my head if there were old code samples in the Windows SDK. I'm on a brand new workstation I built for Christmas so I don't even have my dev environment setup yet.
|
|
|
|
|
You could encrypt it yourself if you don't trust the framework.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I don't have any trouble trusting the framework to encrypt things. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I'm trying to be kind here, aight?
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yeah ... some of my data classes I binary serialize, then encrypt, then compress, then embed as resources. Make them work a little.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Smart, no-one would expect you to encrypt before compressing. 
|
|
|
|
|
Hey there,
Hope everyone is well.
I have a method in my Form1()
public void checkCommand(string command)
{
this.label1.Text = command;
}
I've written an external .dll class library with other methods, which I'm also using inside my main Form1(). But I do need to call a method/methods that are in my Form1() from this external .dll class library. However, I can't access it.
public class Commands
{
private string myCommand;
public void readCommand()
{
checkCommand(myCommand);
}
private void
}
Please note, I'll be using this external class library in multiple applications. So assigning Form1 inside my external dll is out of question, unfortunatelly.
Does anyone know the best solution to this, please?
I'll be very grateful for all your ideas. Thank you!
modified 29-Dec-22 17:20pm.
|
|
|
|
|
Question is not very clear.
C# has classes and methods (static or not.) You cannot access a method without the class.
Beyond that the class must also have a namespace.
So you must resolve the namespace. You must have a instance. You must call the method with that instance. Examples of all of that.
using SomeNamespace:
...
YourClass c = new YourClass();
c.checkCommand(myCommand);
To get to that class (as defined by the namespace) you must have the dll referenced in the binary build. Even to compile it it will need to be available. And of course delivered into an appropriate space (same file system directory) as the primary executable.
|
|
|
|
|
Thank you jschell. I appreciate your involvement.
Apologies, if perhaps I haven't made myself clear.
As per my post above, I've mentioned that I am using external dll. Therefore, I use namespace to it, exactly as per your suggestion. So in my Form1 I can access all methods from my external class library.
To be clear, this is an external dll class for my sockets client.
OnReceive(IAsyncResult ar) I need to display value on label.text in my Form1, or other forms where I will be using my external sockets class dll assembly.
Another method within that class need to call method from Form1 checkCommand(string command). Hope this will help explaining it better
Thank you again
|
|
|
|
|
There's a bunch of different ways of doing this, but NONE of them involve your class library calling a method in the form class.
Looking at your example code, I wouldn't even consider putting that code in the Form class, but instead in it's own class where you create an instead of it and pass that instance to your class library. Of course, that class will have to implement an interface your class library exposes and expects by an implementer.
|
|
|
|
|
You need to add an "interface" (e.g. IFormCommand) to your external dll that your form can implement; then you call into the dll with the interface ("sender" as IFormCommand); the dll can then use to interface to call the form's method(s); as defined in the interface.
You're basically trying to avoid a circular "using" reference (from dll to form) by using an interface (class).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Impossible: for a dll in some unknown app to invoke a method in a WinForm app ... the dll must get passed a valid reference to the Form instance in the WinForm App.
You need to describe in detail what you are trying to achieve.
Theoretically, it is possible to use reflection to enumerate all running processes and locate the WinForm app process of interest ... believe me, you don't want to go there [^]
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Turn the problem on it's head, and ask yourself "does it happen in other code?"
And the answer is "yes": it happens all the time. When something happens in a class, it wants to tell the outside world about it.
When the user clicks a button, when data arrives at a serial port, when a timer expires - they all need to tell your code that it happened. They do this by means of Events which your code subscribes to and processes via a handler method.
The user clicks a button? The Button raises the Click event, your code handles it and checks the data he entered.
Data arrives? The SerialPort class raises the DataRecieved event, your code handles it and processes the characters.
The timer interval expires? The Timer class raises the Tick event, your code handles it and updates the on screen clock.
So why not use the same mechanism in your code? Your external class creates an Event, your form adds a Handler; your external class wants your form to do something, it raises the event, the handler method does the work.
Have a look here: Transferring information between two forms, Part 2: Child to Parent[^] - it's form / control based, but it's exactly the same process for "normal" classes.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
