I've got a branch where I've almost gotten LDAP syncing fully working, but invites don't seem to be working properly.

Even if I try to send an invite directly through the web interface, it just hangs. The user shows in the list, however the logs never show a success or failure response for the request. I've checked the SMTP settings and they appear to be correct. I'll keep debugging though.

https://git.cloudron.io/iamthefij/bitwardenrs-app/tree/ldap-sync

After making a few upstream patches to Authelia, I've gotten an Authelia Cloudron App running! (yay!)

Unfortunately it won't work due to the Cloudron Nginx config. (Bummer!)

Repo and context for those interested https://git.cloudron.io/iamthefij/authelia-app

Would be cool to have still, but I'm not ready to dig through the Nginx changes given how broad the impact would be.

LDAP syncing is now available for bitwarden_rs. Check it out on the wiki.

Do you have your app shared on git.cloudron.io yet? If so I can help contribute.

More debugging weirdness! Looks like the Safari errors can be ignored. The iframe actually seems to be loading fine. I tested using my external link to Gitea embedded in NextCloud. It renders just fine, but the errors still shows in the log. Weird.

Then, within the Collabora frame inside NextCloud, I was getting an error saying:

Failed to read document from storage. Please contact your storage server (cloud.example.com) administrator.

Turns out that was related to open a new document. It now works in Safari with older documents but new documents won't work.

Firefox still gives me the previous error, though I just noticed there is also a different error present, so maybe the X-Frame-Options one is a red herring.

Load denied by X-Frame-Options: https://docs.example.com/ does not permit framing by https://cloud.example.com/apps/files/.
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified

Sorry, this is a lot of info. I'm just dumping it all as I debug for someone's future reference (probably mine).

Just tried in Safari and got much more detailed information:

[Error] Invalid 'X-Frame-Options' header encountered when loading 'https://cloud.example.com/apps/richdocuments/index?fileId=11418&requesttoken=blah': 'ALLOW-FROM https://md.example.com' is not a recognized directive. The header will be ignored.
[Error] Invalid 'X-Frame-Options' header encountered when loading 'https://docs.example.com/loleaflet/blah/loleaflet.html?WOPISrc=https%3A%2F%2Fcloud.example.com%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F11418_blah&title=Test.odt&lang=en&closebutton=1&revisionhistory=1': 'ALLOW-FROM https://cloud.example.com' is not a recognized directive. The header will be ignored.

It looks like both are trying to frame each other. When I did check my settings for cloud.example.com, I saw that I had allowed cloud.example.com to be embedded in md.example.com, so I'm wondering if that's where this is coming from.

Updated both to allow embedding from each other now.

Oddly enough I still get errors saying framing is not allowed.

Firefox gives me:

Load denied by X-Frame-Options: https://docs.example.com/ does not permit framing by https://cloud.example.com/apps/files/?dir=/Documents

Safari gives me:

[Error] Invalid 'X-Frame-Options' header encountered when loading 'https://cloud.example.com/apps/richdocuments/index?fileId=11418&requesttoken=blah%3D%blah%blah%3D': 'ALLOW-FROM https://docs.example.com' is not a recognized directive. The header will be ignored.
[Error] Invalid 'X-Frame-Options' header encountered when loading 'https://docs.example.com/loleaflet/blah/loleaflet.html?WOPISrc=https%3A%2F%2Fcloud.example.com%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F1141blah&title=Test.odt&lang=en&closebutton=1&revisionhistory=1': 'ALLOW-FROM https://cloud.example.com' is not a recognized directive. The header will be ignored.

The header itself shows X-Frame-Options: ALLOW-FROM https://cloud.example.com... which looks right.

Tried that, but it did not fix it. For some reason it still shows the same thing.

FYI, the default is insecure. [a-zA-Z0-9_\-.]*example.com would actually allow someone to use a malicious domain like fake-example.com and use the instance as it would match that regex. It should really be example.com|[a-zA-Z0-9_\-]+.example.com. That way it's checking for root domain or any subdomain with a dot before the domain.

Ok, so I've been racking my brain on this one for a while and can't figure it out.

I've got NextCloud installed at cloud.mydomain.com, and Collabora installed at docs.mydomain.com. I've updated Collabora to allow framing by https://cloud.mydomain.com as well as updated the host name in the app itself. I've also installed the Collabora app in NextCloud as well as told it to look at https://docs.mydomain.com.

This had been working for a while. Today I noticed it just kept spinning when trying to view a doc and see in the JavaScript console the following perplexing line:

Loading denied by X-Frame-Options: https://md.mydomain.com/ does not permit framing by https://cloud.mydomain.com/apps/files/?dir=/path/to/doc

What?! I do have an app (CodiMD) hosted at md.mydomain.com, however, that is something completely irrelevant. Just in case, I updated it to allow framing in https://cloud.iamthefij.com, but that doesn't seem to have helped either.

From there I started debugging. I grepped the /app directories for md.mydomain.com in both my NextCloud and Collabora containers, but found nothing. I tried renaming md.mydomain.com to md2.mydomain.com, but I got the exact same error:

Loading denied by X-Frame-Options: https://md.mydomain.com/ does not permit framing by https://cloud.mydomain.com/apps/files/?dir=/path/to/doc

On the other hand, when I rename docs.mydomain.com to docs2.mydomain.com, I get a NextCloud error that it can't connect to Collabora!

So it seems like NextCloud is connecting to Collabora, but for some reason it's then trying to load a different host...

Nope. I'm on Scaleway.

Ok. Yea. I dug through the code just now and figured out where it was happening and found the log line for the failure.

2019-03-06T11:30:05.242Z box:mail Ignored error - relay: Error: Timeout
    at Socket.<anonymous> (/home/yellowtent/box/src/mail.js:150:18)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:410:8)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

Sometimes when I get sent an email, it shows up in my inbox after a significant delay. At times up to 20 hours.

At times I'll get replies from other people on the thread before I get the original email.

Email logs contain some sensitive info, so not pasting here.