Tim Holloway

Jon Swanson wrote:Why logging into the PC is not sufficient is beyond me- I have to implement the requirement, I didn't request it.

No, such foolish mandates are typically handed down by some genius in management or at least a favored henchman.

If people are going to walk away and leave their computers unsecured, I can pretty well guarantee that sooner or later, they will do so after the sensitive app has been launched and is running. So much for app-specific login.

If it's really that sensitive, my own vote would be to forget passwords and outfit the computers in question with a proximity-activated security device. That is, something that will lock down everything if you step more than a foot or two away from it.

Pfttt. Only 3 middle names? My great-grandfather had seven middle names. He reportedly was so disgusted that he didn't give his sons any middle names at all.

Worse yet, he named one of them "Dee", which cause the poor fellow no end of grief in the military. Officers would demand his name and when he replied "Dee", they'd bark back, "NAME, not initials, dammit!".

I believe he eventually changed it to Donald.

Better yet, you shouldn't have any login code at all. The technical term for user-designed login code is "hacked".

Unless you're a full-time trained security professional, you should avoid creating your own security system. Security is too important to be something done as a secondary consideration in today's hostile world. Even if your app does something as simple as trade Pokémon cards, an invader might re-purpose it to launch malware and/or spam.

J2EE/JEE defines a standard container-managed security system. It's built into all major webapp servers, including Tomcat, jetty, Wildfly and the "big name" commercial products. Typically that system has plugin authenticator modules ("Realms") so that you can keep your userids and passwords wherever and however you want to. For example, Tomcat's MemoryRealm uses a simple XML data file format. The JDBC Realm uses SQL databases, and the JNDI Realm can use LDAP servers such as Microsoft's Active directory.

A lot of J2EE books use a user-written login system for code examples. I wish they wouldn't do that. The Internet is polluted enough.

One thing that is REALLY confusing is the way you say "the project is built on the pipeline" and your "cycles", especially the "Jenkins" cycle. Your terminology doesn't match common usage.

What I'd be expecting to see normally is that you'd have possibly 2 build processes: manual build (where you run Maven from IDE or command line) and Jenkins build (usable to build testing and production releases). In other words, Jenkins not a "cycle", but the Build Controller. I'd also expect that essentially the same Maven POMs would serve whether you're building manually or via Jenkins.

Jenkins itself runs as a pipeline of sorts. I don't know that I'd use that term, since a pipeline is normally used to transport something, and what you really have in Jenkins is a sequence of processing steps. You can arrange those steps to do git pull/compile/build with deployment being a separate Jenkins sequence or you can do a pull/compile/build/deploy as a single sequence.

In any event, it really does sound like Jenkins has nothing to do with the problem at hand. If you really are trying to pull SNAPSHOT modules into non-SNAPSHOT builds, Maven is probably objecting to that. With good reason.

Stephan van Hulst wrote:To clarify, I know about SNAPSHOT versions, but I don't know what OP means by "SNAPSHOT cycle".

I'm taking that to mean that "SNAPSHOT cycle" means development, as opposed to production builds.

I took a quick peek at one of my snapshot-based POMs. Without actually carefully reading David's problem   I would venture that he's trying to do a production build that's pulling in SNAPSHOT dependencies. And that's not something one should be doing. A snapshot should be able to pull in production artefacts (hard to do anything if you can't do that with the Apache libraries, for example!). But a production module should not be pulling in "experimental" code.

Campbell Ritchie wrote:Welcome to the Ranch

Remember that your switch is translated by the javac tool into a lookup table in the bytecode.

Except when it isn't. Sparse-value switches, for example.

While the old expression "Constants - aren't and variables - won't" is a classic, what you have here is two different classes of "constants".

The form "final int varB = 7;" is defining a Manifest Constant. Essentially, it's treated as though you'd always coded the actual value 7 wherever you code varB.

The failing form, however is being treated as an immutable variable. It's functionally the same as a manifest constant except that being defined and initialized in 2 different places means that the compiler must treat it differently (for example, checking for use before initialization and checking for multiple initializations).

My felling is that the compiler probably could treat the two situations identically, but the implementors weren't willing to go to the extra work to ensure it would be so. What if, for example, initialization was done in a base class?

And this is one of the reasons why Java uses the keyword "final" instead of being like C++ and calling it "const".

Stephan van Hulst wrote:I don't know what you mean by "SHAPSHOT cycle" and what you mean by "RELEASE cycle". Are these phases in Jenkins' release pipeline?

Maven has the ability to create SNAPSHOT versions of a build. These can then be posted to a shared repository such as Nexus and there are special management functions. SNAPSHOT versions are essentially informal incomplete editions of their corresponding formal release versions. They're productivity sugar.

I'm not sure what "releasing" in Jenkins means, though.

I'm sure you could create a custom transaction manager in Spring.

But. When you're dealing with objects in two different systems, that's usually something you'd use an XA transaction manager for.

However. When you're working with a persistence system like Spring Data/Hibernate JPA, I would expect that rolling back a transaction would also roll back the persistence system's cache automatically. Assuming that in fact, the internal working objects are even cached  before the transaction is formally committed.

Are you sure you're not worrying about things you don't need to worry about?

Incidentally, many databases (like PostgreSQL and MySQL) will not accept a valid user ID and password unless it's from an authorized IP. Knowing that the password of the FORT_KNOX database is "swordfish" is of limited use if the only machine that can submit those credentials is locked inside a secure data center where only authorized support personnel can log into it. Stuff things on a VPN and set up decent firewalls, and you're as close to impregnable as IT can be.

It's worth remembering also that many intrusions aren't due to breaks in basic security, but rather due to insiders doing things they shouldn't or leaking information that they shouldn't. Security is as much about knowing whom to blame if things go wrong as it is about actually locking people out.

PING uses ICMP and PING does not require root privileges, so I'm doubtful on that assertion. And while many hosts don't respond to PING any more, that's mostly the decision of the host rather than the LAN. It's hard to troubleshoot a LAN without any PING at all.

Multicast is the most efficient use of network resources, and it's the preferred way for Autoconfig network services to make devices aware of each other. The catch is that a well-secured public LAN will typically be locked down for all ports and protocols except for HTTP, HTTPS and the mail protocols. And DNS, of course.

In fact, I think that zerofconf services like avahi run a hierarchy of probles, starting with multicast and proceeding through less efficient but more accessible means until it reaches HTTP. But it's been a while since I read up on details.

paul nisset wrote:JNDI and context.xml are excellent for general information like DB server paths etc. But I wouldn't want to put passwords in them.  
It doesn't really resolve the security of issue  having passwords readily accessible to anyone who has access to the web server having the keys to the kingdom all in one convenient place.

I've seen people put DB passwords in web.xml (luckily not often). It's quite shocking.    

As a rule, however, if someone has access to the server-specific deployment information, they already essentially own the server anyway.

I'd be glad to hear how you do it, but as far as it goes, most of my deployment info passwords are database passwords, so storing passwords in a database would be problematic - you'd need a password to get a password. So would storing them in LDAP, since you'd need to have the LDAP credentials.

You're better off using security certs than passwords. The certs can be better secured and generally won't work on any machine but the one they're created for.

Cornelia Davis wrote:Love your practices Tim.

I've had a long and evil career. I learned long ago to make stuff as idiot-proof as possible. Especially from when I'm the idiot it needs to be proof against.

Carey Brown wrote:OK, but then how do you place a series of lines in 10 degree increments.

Who says I want to? The point is to draw a circle, not to artificially limit myself to a set of fixed angles. Especially when you consider how much different a 1 cm circle plotted with 10-degree increments would look on-screen compared to a 10 cm circle.

I really don't (strongly don't) recommend configuring Tomcat using META-INF/context.xml. My own  very strict policy is that the same WAR should be deployable unmodified on desktop, test and production servers. That ensures that when production goes sour that I know I'm working with exactly the same code and resources back when I try to diagnose and repair the problem on my local machine. And it also ensures that the wrong deployable doesn't end up on a server that it shouldn't and thereby do things like corrupt production databases because it was being used for testing.

I think the safest way to upgrade a webapp is to undeploy and redeploy. If your application uptime is so critical that you cannot accept the small amount of time it takes to do this, then I'd recommend running a cluster so that you can keep running old copies of the app on some nodes while upgrading on others until you have the entire set updated.

One of the biggest reasons I don't encounter this problem myself is because I don't just plunk down stuff into Tomcat. Most commonly I build OS-installable packages that include the new WAR, context xml file and any other extra-WAR support files. This is actually pretty easy to do with Maven or Ant. Some people even deploy straight from Maven, Ant, or whatever their preferred build system may be.

Other people like to do more of a continuous-build process and use Jenkins or a similar product to push out the updated WARs and their context configurations.

I'm not sure, but I think that example expects other machines on the subnet to have resolvable hostnames, and I doubt that a third-party LAN would be able to handle that. Or at least my local routers couldn't. So you might want to modify that code so that instead of looking for hostnames, it does a quick request on each eligible IP address to see if your messenger app responds.

Be aware that you'll be doing looks to a LAN administrator a lot like a potential attack, since it's flooding the LAN with probes. I doubt a cruise ship will be employing a very sharp administrator, but it is possible that someone might notice and contact you.