Calibre returns 404 when visited through .onion address

Support
1

Problem Description
Calibre is not accessible via the .onion site (Onion site is available, login and other apps function as expected via onion site)

Steps to Reproduce Success

  1. Login to FreedomBox via local/IP
  2. Launch Calibre
  3. There be all the Books

Steps to Reproduce Error

  1. Login to FreedomBox via .onion/Tor Browser (tried on Debian and Android)
  2. Launch Calibre
  3. There be no Books, no Books at all : (

Apache autogenerated 404 page

The requested URL was not found on this server.

Most Useful Clue Found
in the file /etc/apache2/conf-enabled/calibre-freedombox.conf is the apache <Location /calibre> block:

    ProxyPass http://127.0.0.1:8844/calibre
    Use AuthOpenIDConnect
    Use RequireGroup calibre

    # Calibre has a bug where an empty value for a HTTP header is treated as
    # invalid. OIDC_CLAIM_email can be empty and this causes Calibre to error
    # out. So, try to pass all the OpenID Connect user information and claims as
    # headers that can't have an empty value.
    OIDCPassIDTokenAs "serialized"
    OIDCPassUserInfoAs "json"

when modified, as follows:

    ProxyPass http://127.0.0.1:8844/calibre
    #Use AuthOpenIDConnect
    #Use RequireGroup calibre

    # Calibre has a bug where an empty value for a HTTP header is treated as
    # invalid. OIDC_CLAIM_email can be empty and this causes Calibre to error
    # out. So, try to pass all the OpenID Connect user information and claims as
    # headers that can't have an empty value.
    OIDCPassIDTokenAs "serialized"
    OIDCPassUserInfoAs "json"

the calibre app loads (and functions) through the tor browser. Unfortunately, it allows unauthenticated access to all calibre functionality.

In case it helps, disabling one or the other does not work, only both.

I’m not intimately familiar with the inner workings of Apache, so I don’t know what would cause the AuthOpenIDConnect or RequireGroup (separate?) modules to presumably choke on the onion address.

I haven’t been able to identify any pertinent error logs.

In case it also helps, I tried this from an admin account, and, also tried manually adding the user to the calibre user group (though, the admin account does have access via local/IP, so I didn’t expect it to matter.

Information

You are running Debian GNU/Linux 13 (trixie) and FreedomBox version 26.8. FreedomBox is up to date.

  • x64 server
  • apt install freedombox
2

Continued Digging

Calibre in FreedomBox appears to rely on the mod_auth_openidc apache module.
This module appears to refuse to resolve .onion addresses.

My Digging

In the /var/cache/apache2/mod_auth_openidc/metadata directory, where the configurations are for each of the domains freedombox serves (domain, domain.local, etc), each has both a .client and a .provider JSON configuration file.

There is no .provider file for the .onion address domain, just a .client file.

I enabled debugging by adding the line:

LogLevel auth_openidc:debug

in the /etc/apache2/conf-enabled/10-freedombox.conf file (explained in comments of the file, above the Macro block) - which may have enabled the necessary logging in journalctl, or may have done nothing (I didn’t check again with it off to confirm).

After that, I copied the localhost.provider file to a domain.onion.provider file, replaced the domain name occurrances in the file with the onion domain, reloaded the calibre page via torbrowser, and found in the logs (journalctl -xeu apache2) that OpenIDConnect is refusing to resolve .onion addresses, according to RFC 7686.

Beware if you attempt this yourself, there is a red herring: you must access via HTTPS. Going through HTTP to the .onion address returns a different error, a result of openidc requiring HTTPS.

So, My New Question Is

Is there a way around this, so that me and my homies can share books via the calibre library, over tor? Or am I going to be building a custom tool by hand instead?

An acceptable solution, to me, would be to disable authentication for Calibre over the .onion domain, and allow read-only connections (and leave the management of calibre to LAN-only) - or to disable authentication via openidc entirely, and protect access to calibre via a different method such as a separate htaccess or a simple password.

If I attempt this, I will return with the results/solution.

3

Temporary Solution

I modified the /etc/apache2/conf-enabled/calibre-freedombox.conf as follows:

    ProxyPass http://127.0.0.1:8844/calibre
    #Use AuthOpenIDConnect
    #Use RequireGroup calibre
    Include includes/freedombox-auth-ldap.conf
    Require valid-user
    RequestHeader set X-Remote-User expr=%{REMOTE_USER}

    # Calibre has a bug where an empty value for a HTTP header is treated as
    # invalid. OIDC_CLAIM_email can be empty and this causes Calibre to error
    # out. So, try to pass all the OpenID Connect user information and claims as
    # headers that can't have an empty value.
    #OIDCPassIDTokenAs "serialized"
    #OIDCPassUserInfoAs "json"

so now access to calibre requries a valid username and password combination.

I modified the calibre-server command args in the service file /usr/lib/systemd/system/calibre-server-freedombox.service to disable write access, which was also successful, though I ended up re-enabling write access after restricting access to the Calibre server to valid users only.

Now ANY valid user can upload/modify ANY Calibre library. This works for me, but is not an actual solution, since now access is granted differently from how it’s documented. I have no final solution to propse (and I’m done exploring), but between this method and modifying calibre-server’s members and built-in access-control mechanisms, there are various solutions for anyone looking for their own workaround : )