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
