Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Can I run the demo container image with useHttps=false?

See original GitHub issue

Hey there. I’m so glad this project exists. Thanks for working on it and helping me out.

I’m wondering if it’s possible to run the datatransferproject/demo container image from docker hub, but in such a way that it listens for http requests, not https. This is because I’d like to access the running container through a reverse proxy that I’d prefer speak http to the application.

Currently, when I follow the instructions for Run Locally, and then issue an http request like this, I get an error:

$ curl http://localhost:3000
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.10.3</center>
</body>
</html>

Of course, curl -k https://localhost:3000 works, but only because of -k. I’d like to be able to run the image such that the above request succeeds with an HTTP 200 response.

I can see in here that it’s possible to configure the application such that useHttps=false. But AFAICT, this yaml file has to be built into the jar file that is run by this docker container, and that jar file in the docker hub image is preconfigured to have useHttps=true.

I’m a noob when it comes to Java. Is there any way for me to run the docker hub demo image in a way that useHttps=false? For example, by setting an environment variable and/or mounting a custom configuration file.

If not, would it make sense to add this as a feature to how the app boots up? I could pass an env variable pointing to my own common config yaml file (or alternatively env variables for each config like useHttps).

In lieu of advice or such a feature, the only way I can think of doing this without building/hosting a custom image is to somehow override the container image’s command to:

unzip the /app/demo-server-all.jar contents
edit config/common.yaml (or api.yaml?) to add useHttps: false
rezip the jar
run the jar as the image otherwise would

Thanks for your advice!

Issue Analytics

State:
Created 4 years ago
Reactions:3
Comments:11 (6 by maintainers)

Top GitHub Comments

1reaction

jimmarinocommented, Nov 15, 2019

Is it possible to use those vars to point to files outside of the jar, e.g. docker-mounted paths?

I quickly re-checked the code and it looks like there is some inconsistency in the codebase to where configuration is being sourced. If you want to just replace the YAML settings, I think the easiest way will be to create an extension I outlined above.

A while back I created an example of how to write custom extensions (and a custom build for the UI) here:

https://github.com/Metaform/data-transfer-starter

I think the custom config extension should be fairly straightforward to build. I see a couple of ways this could go:

Create an extension that only sources for env settings. This would completely replace the YAML variant.
Create an extension that sources from a YAML and if not found sources from env.

Option #2 would be a little more complicated and I can think of two approaches. The first approach would involve creating an extension that replaces the YAML one. This is not ideal because it would lead to duplicate functionality. The second approach would be to enhance the core runtime to allow for multiple sourcing strategies, e.g. try the YAML extension first, then the env one. This could be done by introducing an ordering mechanism in the ServiceExtension signature.

This may seem more complicated than just hardcoding the env sourcing option. However, I think it is important we give people the flexibility to remove that behavior entirely from the runtime.

If you would like to work on this, I’m happy to help out and collaborate.

1reaction

jimmarinocommented, Nov 15, 2019

Since you’re asking, it sounds like that path would add code/abstraction, a small cost to be fair, but I’m not sure what it would gain over the alternative of a one-line change I had in mind.

This would avoid app code having to muck around with the DOM and centralize this process.

Would it? It sounds like EnvironmentService would still be using the DOM API? If anything it sounds like this would move DOM specifics into the app and it’s services, instead of it being used just to get a configuration value to boot up the app (but the app wouldn’t care/know that the value had come from document.baseURI.

Hi @gobengo

The Angular way is to source this from environment, which is replaced at build time and then referenced by services in the application to construct URLs.

My initial read of what you are you proposing was to replace this mechanism with each service making a request to construct its URL by accessing the DOM. Reading your latest response, it seems that you are proposing to modify the default environment.ts file to create apiBaseUrl from the DOM. I’m OK with this as long as it is not used for the production config (environment.prod.ts). You’re right that approach will be less invasive than the injectable service I was proposing 😃