@girish yea. Exposing a secure proxy to the LDAP server was my first plan. After I found Authelia, I figured this would be a somewhat simpler option...

Unfortunately, it doesn't actually appear to be so simple.

I was thinking of a using a containers to bridge a connection to the LDAP server via a VPN, but I haven't gotten around to figuring it all out yet.

@girish wow! I had no clue that exec worked that way. TIL! Is there no garbage collection process? Seems strange. My host probably has a bunch of dangling execs. They’d seem like they’d be benign, but I wonder.

HTTP access would be a great way to solve this. Happy to help test or debug.

@girish The headers are intended to pass along the information about the original forwarded request. In the case where trying to use forward authentication against a host, let's say cloud.example.com, the X-Forwarded-Host for the initial request to the reverse proxy would be cloud.example.com. When performing forward auth, a new request is made to the auth server at auth.example.com, without modifying the X-Forwarded-Host header, as this is all still considered part of a request to could.example.com.

My original suggestion may actually not be secure. So let's ignore that for now.

The other way to solve this would be to host on a custom port and access via IP address to avoid the reverse proxy, but I'm not sure I like that as it would require more work to use TLS. I can try to dig into the examples of Authelia with Nginx some more and see how they configured this part. I have thoroughly forgotten where I left off.

@girish

We used to use exec before but we removed it because there was actually no way to clean/delete exec containers (not sure if they have fixed this now). Those exec containers will basically hang around, so for a scheduler this means a new container keeps getting created and just accumulates garbage.

I'm not sure I follow. Using docker run actually creates a new container by default. That is unless the --rm option is added. If added, it will remove the container after running. This is actually what Cloudron appears to do today.

In contrast, docker exec doesn't create any new container. It runs a process within an existing container. There is no need to clean up any containers after execution.

If the issue is that poorly written cron jobs are deleting files that should not be deleted, that sounds like a bug with the app, not with box. There are legitimate reasons to want to access the same filesystem. Maybe it's cleaning up logs or something. Periodically sending out files. Or, as in this case, accessing a SQLite database.

Also, any reason why the "syncing" is not part of the main bitwarden_rs binary itself?

That was a design decision by the original Bitwarden creator. Bitwarden_rs decided to follow the same convention.

That way the scheduler can just call bitwarden_rs ldap-sync instead of doing a http call?

Unfortunately, that would not get around this issue. Executing bitwarden_rs ldap-sync from a new container (created by docker run) would not have access to the same filesystem, and therefore it would write to a new SQLite database that would immediately be cleaned up.

@iamthefij @girish do you remember why this header is being written? Any idea what effects of this type of change would be.

@girish any ideas on this?

@nebulon in order to determine what application to authorize, Authelia needs to know what URL was forwarded to it. Since Cloudron overwrites this, Authelia always thinks you’re trying to authorize access to the Authelia domain.

A simple fix would be to only set the headers if the header is not already set.

Do you recall what apps required this header? I can do some more digging into how headers are set with the Authelia example configs and maybe come up with a more flexible patch. Possibly setting up an app add on to pass through headers.

Hey @nebulon, @girish . Any ideas how I can proceed to make this work for Cloudron?

I'm happy to patch box to use exec rather than run, or provide an option, but it's unclear why the decision was made to do run in the first place.

@nebulon any idea how I can get some clarity here so that I can deliver this app?

I'm blocked on getting the app working without a little guidance from @girish on why nginx is overwriting the X-Forwarded-* headers.