Access Solr admin over HTTPS in DDEV by default

[gitressa]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem?

In Firefox, you need to disable HTTPS-Only Mode in Firefox to access Solr, since it's using HTTP, which is not ideal.

Describe your solution

It would be great with Solr access over HTTPS as the default, if it's possible.

Describe alternatives

No response

Additional context

Kevin Quillen's blog post Access Apache Solr admin over HTTPS in DDEV.

[rfay]

My experience is that it all goes bad with HTTPS enabled, but the right place fof this issue is ddev/ddev-solr, so I'll move it there.

[mkalkbrenner]

environment:
      # This defines the host name the service should be accessible from. This
      # will be solr.sitename.ddev.site.
      - VIRTUAL_HOST=solr.$DDEV_HOSTNAME
      # HTTP_EXPOSE exposes http traffic from the container port 8983
      # to the host port 8983 vid ddev-router reverse proxy.
      - HTTP_EXPOSE=8983:8983
      - HTTPS_EXPOSE=443:8983

OK, this isn't true HTTPS between the router and Solr. But it makes sense as simple workaround for Firefox and also your app uses CSP headers to redirect to HTTPS.

[mkalkbrenner]

I'll add this after the Solr 9 support is committed.

[rfay]

The HTTPS_EXPOSE has been problematic in the past because the Solr admin did an odd redirect on some/many browsers. Hopefully that's fixed. But that's why it was removed in previous revisions.

[mkalkbrenner]

Using port 443 might cause conflicts with the application if it serves /solr as well.

[mkalkbrenner]

If I add HTTPS_EXPOSE=8943:8983, ddev status gives me https://dummy.ddev.site:8943.
This gets redirected to http://dummy.ddev.site:8943/solr, which doesn't work (http instead of https).
If I enter https://dummy.ddev.site:8943/solr manually, it works.

@rfay is there any way to append /solr to the URL shown by ddev status?

[rfay]

Great troubleshooting.

DDEV doesn't have a way to know what the default URI should be (it auto-discovers the port). But you might consider a solr custom command added by the add-on. Then people could do ddev solr, or ddev solradmin. Just a knock-off on all the many other custom commands that do a launch, like ddev phpmyadmin. https://github.com/ddev/ddev-phpmyadmin/blob/main/commands/host/phpmyadmin

Related:

• Add configurable details for "INFO" in ddev describe output e.g. for addons ddev#5469

[rfay]

@kevinquillen article on a solution, https://kevinquillen.com/access-apache-solr-admin-over-https-ddev

@kevinquillen if this can be done reliably, how about a PR?

[mkalkbrenner]

@rfay as mentioned above in #27 (comment) the suggestion by @kevinquillen works, but the link in ddev status breaks.

[kevinquillen]

@mkalkbrenner @rfay that would be fixed with this change in a future release, right? The output will reflect the host and port overrides. I haven't quite had an issue with https redirect otherwise.

ddev/ddev#6136

[stasadev]

I got to the root of the problem:

• feat: enable HTTPS support, fixes #27 #39

[stasadev]

@mkalkbrenner
This won't work 0398b27
HTTPS support is only for the UI, meaning you still need to access it via HTTP inside the container.

[stasadev]

I forgot about the tests, but you still can test HTTPS here:

ddev-solr/tests/test.bats

Line 23 in 0398b27

if curl --output /dev/null --silent --head --fail http://${PROJNAME}.ddev.site:8983/solr/techproducts/select?q=*:*; then

See:

• test: add check for the correct admin UI redirect, for #27 #40

[rfay]

@kevinquillen does this make your article obsolete?

[kevinquillen]

I think so. This fixes the https redirect, the other shows customization. The PR I made last month will make the ddev describe reflect all cases correctly.

[rfay]

And

• feat: output the VIRTUAL_HOST if specified in environment variables of a service ddev#6136
  was merged and is in DDEV HEAD.

[gitressa]

Thanks everyone! It's so great to be able to access Solr over HTTPS.

[gitressa]

I created a follow-up issue #41.