Interesting. Thanks for the explanation. I'd actually never thought of / heard of that kind of thing happening, but that's good to know.
~Roger -----Original Message----- From: Josh R [mailto:[email protected]] Sent: Wednesday, August 08, 2012 1:05 PM To: [email protected] Subject: Re: How to block UI input to a disabled/busy TreeNode On Wed, Aug 8, 2012 at 3:46 PM, Roger L. Whitcomb <[email protected]> wrote: >> The application that I'm targeting is similar to IPMI remote login but a >> more complex version. Depending on the state of the host/hardware we might >> have to juggle different fields. So it's best to handle that in code rather >> than writing several different bxmls. > > Okay, got it. I can see how that would be hard to handle in bxml. > >> Also what if someone tampers the bxml? > > Interesting security question.... But, along that line, if someone is really > interested in hacking your application, what's to prevent them disassembling > the byte code back into Java source and changing it that way also? My point > being that if there is a significant security risk if someone were to change > the bxml (presumably they are in your packaged .jar file, right?) then you > probably need to implement some other checks somewhere so that the > application can (at least) detect if things have been tampered with since the > .jar file was built? > > ~Roger Hopefully some code obfuscator will work. The goal is to deter casual mischievous snoopers. I've seen a few cases where some folks at the customer site prefer vendor-A vs vendor-B and then they sometimes play dirty tricks and file support issues just to make the software-offering look bad. The gui will talk to tightened *nix/BSD hosts which doesn't let users run privileged commands. thanks
