What’s in THIS environment?

We work on multiple java web projects going on at the same time and those are all being tested on several different QA environments. Id like to show on our support portal what projects are in what environments without having to manually updated it all the time. I was thinking of some what to tag the build so I could just query tomcat or those linux servers themselves and show the results. The tags would be something like “August Release”, “Project 1”, “Project 2”, etc.. Has anyone done something similar? I’m looking for different options.

Go to Source
Author: DaveTX

Using a domain model to persist metrics

I am currently developing a spring boot web application in which no entity is persistent, and hence will not be saved on a database.

Although, I need to be able to query some business metrics from it. Suppose the following scenario:

  1. EntityA belongs to a third party API.
  2. An user on my web app requests to see some details of EntityA.
  3. My app then requests EntityA from the third party API, does some processing (could be combining that data with some other available on the web), and returns the desired info to the requesting user.

I am not required to persist EntityA because it is already being persisted inside the third party API. All the processing done is transient. But, I want to be able to check how many times EntityA was requested by an user on my web application, and what data it contained on each request. This metric is useful for audit purposes, for example, since the third party accepts input and output of data. I want to be able to check who input a certain piece of data, and how many times it was done.

If I were to persist EntityA, I would not need all fields that the domain model contain. Also, I would have to add some metadata fields to it (date of request, requesting user, etc.).

What is the correct approach to it?

  1. Persist the domain model of EntityA in my web app, adding the metadata fields on, for example, a superclass?
  2. Create a new entity that express the desired metric, for example RequestedEntity, and map the desired fields of EntityA to RequestedEntity before persisting?

Go to Source
Author: Gabriel Robaina

Link in Java returns HTTP instead of HTTPS

Many times your application can be running behind a reverse proxy or a load balancer, and often in between the protocol is just plain old HTTP. This is a very common setup and one that has been around for several years.

When this happens, when generating URLs through the Java Link class on Spring boot, you might get the wrong scheme or protocol. What should have been HTTPS becomes HTTP. When you’re building APIs that follows HATEOAS/HAL, this becomes an issue. With just a single letter ‘S’ your URLs become invalid.

First off, this should be already handled properly by the underlying framework but if the proxy in front of your app was misconfigured this leads to the problem happening and it is then difficult, maybe impossible, to tell whether the client connecting to the app used HTTP or HTTPS.

Luckily, you can force it somehow to use the proper protocol. This is a solution nonetheless, which works, but I would say having the reverse proxy or load balancer configured correctly is the proper way to do it.

ANSWER

The band-aid solution is to manipulate your Spring Boot app depending on the environment.

For example, if I’m just developing/using it locally HTTP is fine. With profiles setup as it ought to be – dev, test, prod – you can get the correct environment and have your URL use HTTP or HTTPS depending on it. When you deploy it to your server, you know you want it to be using secure HTTP so now you can override the Link to use the right scheme in this case.

Here is a one way on how to do manipulate the protocol or scheme of a Link.

Oh, and getting the profile can be done in 2 ways that I know of in Spring Boot.

First is injecting it via annotation.

@Value("${spring.profiles.active}")
private String activeProfile;

and/or autowiring Environment

@Autowired
private Environment environment;
 
public void getActiveProfiles() {
   for (String profileName : environment.getActiveProfiles()) {
      System.out.println("Active profile: " + profileName);
   }  
}

How to prevent from DNS spoofing in Java code which obtains a name of localhost

FORTIFY static scan has detected that this piece of our java code is vulnerable to DNS spoofing attack:

public String getLocalhostName(){
    try {
        return Inet4Address.getLocalHost().getHostName();
    } catch (UnknownHostException e) {
        return null;
    }
}

FORTIFY also gives these recommendations:

Recommendations:

You can increase confidence in a domain name lookup if you check to
make sure that the host’s forward and backward DNS entries match.
Attackers will not be able to spoof both the forward and the reverse
DNS entries without controlling the nameservers for the target domain.
This is not a foolproof approach however: attackers may be able to
convince the domain registrar to turn over the domain to a malicious
nameserver. Basing authentication on DNS entries is simply a risky
proposition.

My questions are:

  1. Is getting the local host name really vulnerable to such an attack ? I can’t imagine such a scenario.
  2. How to implement this check in practice (in this code snippet)?

Tkank you.

Go to Source
Author: krokodilko

How to manage user java deployments in a small team, across different java applications (which require different java versions)?

I provide a java application (desktop client) which requires jdk11 (it really does).
We installed that SDK on all users and were happy for a while.

Then, someone shared with us his java application (also a desktop client, but unrelated to mine), which only works with jre8 (he is not willing to recompile to 11 and his status in the company is such that we must conform to him at all costs)…

I’ve instructed the team members to change their JAVA_HOME between an installed jre8 and jdk11, as they need, but this doesn’t seem like more than an annoying manual stop gap.

I am wondering what is a good, modern approach to allow, for example: a system-wide jre8 for the applications I don’t control but also code a little something into my project that can switch to jdk11 for the duration of their use of my application?

Since I am delivering a project with source code (which compiles every time they run, because they sometimes need to modify some of the java code), I am thinking along the lines of including a portable jdk11 and have the project refer to that as the SDK, relatively (so that they don’t have to install anything to get my application going).

I actually tried this a little bit but couldn’t get it done and I am wondering if it’s a good approach that is worth fixing or there is a better idea?

Can you share your experience about this relatively common problem?

Edit: + I am not sure a containerized solution is viable. It sounds like I’ll have to help them set up their system to support that and then wrap my project in a container – which sounds like a can of worms for someone with my skills (middleweight java dev, at best)

Go to Source
Author: DraxDomax