|
Message Removed
modified 10-Jul-18 13:26pm.
|
|
|
|
|
Hello,
Do we have any way to check or monitor the activeness of any layer or component in any WPF application ? I heard about WatchDog mechanism to use for this purpose but couldn't get any proper information.
My Scenario -
ComponentOne (ClassLibrary)
||
|| reference being used in ComponentTwo
V
ComponetTwo (ClassLibrary)
||
|| reference being used in ComponentThree
V
ComponentThree (.exe/view)
On view i want to show the health of above two component something like Active-if everything is fine, Dead- if any Thread is aborted etc.
we need to introduce a mechanism that the GUI knows if the Interface is still intact/alive/responding etc.
What I have tried:
Read about WatchDog but no luck
|
|
|
|
|
Search for a taskmanager-example here on CodeProject; it will show how to get a list of processes, and whether or not those are active.
That will only apply to the main-thread; other threads do not need to report anything.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I have seen projects in which they are following the method of creating models as interfaces(without any concrete implementation) and mapping them using Fluent API. The reason for such an architecture is to have multiple inheritance. I am not able to digest the reason because as per my understanding interfaces are contracts which needs to be implemented and to make loosely coupled models-view architecture. Please confirm which approach is correct.
|
|
|
|
|
At some point, there's going to have to be a concrete implementation of the interface. The idea of creating a model as an interface is a good way to defer the responsibility of the creation of the model. One reason you might want to do this is because your model has to be filled from a database but you want to write unit tests for the classes that have dependencies on the model without worrying about how to create the model; in a case like this, your class would refer to the interface and your tests would inject a mocked up model that has no database interaction whatsoever. This is a good way to isolate and test your functionality.
This space for rent
|
|
|
|
|
But in this case those properties in Interface Models are mapped to external database fields either by attribute based mapping(Glass mapper) or by fluent api mapping.
|
|
|
|
|
It doesn't matter. As the code only refers to the interface, you can substitute in any implementation. That's what makes it substitutable and testable.
This space for rent
|
|
|
|
|
So after my last post on this I did some research and now I have a question.
From what I can see the idea is to Hash the password, then store it to the DB. Next, you Hash a string and compare it to the stored value. This is all done on the server where it's most secure.
The part I'm questioning is that it seems that you have to pass the PLAIN TEXT password to the back end to do the comparing.
What's the right way to do this?
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
If it's a website, then yes, generally it's a plain-text password that gets transferred to the server - which is insecure but then so is sending a hashed password for comparison!
Provided your login page is SHTML so it's via an encrypted connection, that isn't a problem, because the password isn't transfered over the web in clear, so it's difficult if not impossible to set up a man-in-the-middle attack to access the "raw" password.
Once it reaches the server, it gets salted, hashed, and compared.
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
He could always encrypt the password in order to transfer it, decrypt it after it's transferred, and then hash it to compare with the database content.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Except that means the encryption key needs to be available to the javascript... 
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Joking again?
(That's precisely what HTTPS does.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
No, not joking. HTTPS has been proven insecure (there was a big kerfuffle over that realization a couple of years ago), so why solely rely on it? It shouldn't be difficult to set up.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: HTTPS has been proven insecure
That's a pretty bold claim. Do you have a link to back that up?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
No, but I'm almost positive you have access to google. I don't recall the specifics.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I've seen a few conspiracy nuts claiming that HTTPS is an NSA / Google plot to destroy the internet, but their claims are just laughable. 
Troy Hunt: Don't Take Security Advice from SEO Experts or Psychics[^]
HTTPS Anti-Vaxxers; dispelling common arguments against securing the web[^]
Beyond that, as Eddy said, there were a couple of downgrade attacks which would make your request slightly less secure - but still more secure than not using HTTPS in the first place. Those have been fixed now, but I suppose there could be others which haven't been discovered yet.
But as Griff said, encrypting things in Javascript means the encryption key has to be public, so it doesn't really add any benefit.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: encrypting things in Javascript
We're in the C# forum so you'll have to excuse the assumption that we were talking about C#. JavaScript is evil and should be avoid at all costs. I equate it to using Active-X in regards to evility.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
OriginalGriff wrote: If it's a website, …
I was assuming we were talking about a website, where encrypting things on the client would mean using Javascript.
I guess it's true what they say about "assume".
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Trouble is that when you start talking about passwords, and "back end" or client / server architecture, nearly all the time you are talking about a javascript based client (which while execrable is vastly safer than Active-bloody-X was) - and that means public source code, and public encryption. Nasty. 
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
There were some protocol downgrade attacks, but that should not happen on a modern machine.
So, which insecurity?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"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 recall specifically. In the end, there's absolutely nothing wrong with an additional layer of security. I was just tossing the idea out there.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: In the end, there's absolutely nothing wrong with an additional layer of security.
There is!
It adds complexity, a point of failure, and hence, a point of attack. Think of it as using two condoms; you think you're safer, while the integrity of both lubbers is not guaranteed.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
You're confusing specific issues with general insecurity. HTTPS over SSL has been prohibited,. TLS should use version 1.2 or later (with no fallback to SSL.)
Heartbleed was a vulnerability in OpenSSLs implementation of TLS heartbeats, which has been fixed.
HTTPS over TLS is secure (for now; all security can, and will, be broken in time.)
|
|
|
|
|
Kevin Marois wrote: The part I'm questioning is that it seems that you have to pass the PLAIN TEXT password to the back end to do the comparing.
What's the right way to do this?
That is the right way.
Hashing on the client would prolly mean that your salt is no longer as secret as you like. It's not done to make the password unreadable during transmission, but to "not" have to store a readable version. Even if the datastore is leaked, hashed passwords are useless.
Imagine me hashing and salting my CodeProject-password on the client, before entering it, and with keeping "my" salt private - would CodeProject in that case not act like my password is a plain text? To CodeProject, the hashed string would seem just like a plain-text password and behave in the same way for all purposes.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
That's precisely why you should never send or load ANYTHING over http if it's got anything to do with passwords (or other sensitive data) - Https encrypts which protects the plain text that you send to the server, and prevents eavesdropping via a man in the middle - hence why everything is loaded via https (if it's not, then you can't guarantee anything)
Troy Hunt has some good explanations on the whys and wherefores
C# has already designed away most of the tedium of C++.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
