Yes it will put the raw value into the XML config and then also restart the collabora server in the background. For the actual value, I don't know either, you may have to ask the collabora community for that.

I am no WOPI expert and also cannot reproduce this still. A 403 status code would to me more look like the accesstoken (which is different in both requests you pasted) is invalid. But could be that Nextcloud does return a 403 also for blocked IPs. You have to ask the upstream developers for such details.

One idea, can you double check which IP range your local cloudron docker network uses? You can do this via SSH docker network inspect cloudron

I think I managed to fix the problem now. @Benoit the latest just published package works fine with Nextcloud again.

The main problem with multiple domains is, that most apps produce URIs on the backend, while that one mostly has no clue about which domain it should use if multiple ones pointing to it...

Not sure if related but according to https://www.collaboraoffice.com/code-22-05-release-notes/ in CODE 22.05.10 , "Timezone support
Now we have internal support for respecting the client’s time zone. There were some operations, e.g. “Insert – Time” when the users expected their time, not the server’s time, and now this has been addressed."

@BrutalBirdie While playing around to overcome this error. I found an alternative solution. It doesn't fix the collabora CODE font issue mentioned here, but makes it possible to add fonts to a Nextcloud instance hosted via cloudron.

It works with Nextclouds' ability to add fonts as remote_fonts therefore do the following:

Add the desired fonts at https://[YOUR.NEXTCLOUD.DOMAIN]/settings/admin/richdocuments Switch to the apps-filemanager of your cloudrons Nextcloud. Create the folder ~/apps/richdocuments/settings Find out in which [APP-DATA-DIRECTORY] Nextcloud saves the richdocuments-data inside the directory ~/data (e.g. appdata_ocv42l2jdx7f) in the newly created folder, create a file fonts.json (so ~/apps/richdocuments/settings/fonts.json exists) with the content { "kind": "fontconfiguration", "server": "[YOUR.NEXTCLOUD.DOMAIN]", "fonts": [ { "uri": "https://[YOUR.NEXTCLOUD.DOMAIN]/[APP-DATA-DIRECTORY]/richdocuments/fonts/[FONTNAME-1].ttf" }, { "uri": "https://[YOUR.NEXTCLOUD.DOMAIN]/[APP-DATA-DIRECTORY]/richdocuments/fonts/[FONTNAME-2].ttf" } ] } restart the collabora app restart the Nextcloud app

Additional, remove any font added to the collabora fonts directory...

Edit: After trial and erroring even more, I found nextcloud updating the fontlist only if ~/apps/richdocuments/settings/fonts.json is again saved.

Edit-2: Unfortunatly after a collabora update nextcloud needs to be restarted again to make the font changes again available…

@nebulon maybe this might solve the issue?
cheers

So there are some logs on the Nextcloud side too. It shows returning a 403, not authorized. It seems like the token it's retrieving is invalid or something. I didn't find anything too promising when searching Nextcloud forum either. I'll keep poking.

Support couldn't reproduce it for now so they just ignore it for now as it's not critical. Maybe someday we have an idea on what causes this.

@RazielKanos I pushed an update yesterday with language packs for collabora. Can you check if the situation changes with the new package?

This thread - https://forum.cloudron.io/topic/8978/nextcloud-office-and-onlyoffice

@ApplegateR @staff good news I found a problem I had to add 'https://yourcodeoffice,donain.com'

I was putting it without https:// that why it loading too long and keep access to insecure certification or something bug on here but hey it work again

Yes, as far as I understand each Nextcloud would initiate a document edit session with its own document URL and token exchange, so those should be isolated from one another.

@nebulon I can't share the original document publicly, unfortunately, but the problem has disappeared after having raised the PHP Memory Limit in Nextcloud from 512 MB to 2 GB.

The reason for the crash was that the app by now needs more memory. The app package with more language packs is out now. However one needs to adjust the available languages in the coolwsd.xml via the filemanager, to enable them. An app restart afterwards is required.

This seems to be a highly app specific issue. As far as I remeber, code renders document tiles which is what appears to be rather slow for you. As those are possibly only very short amounts of time where cpu spikes, it may not show up, but might be worth looking at htop via SSH during scrolling and see if the CPU is the problem. Otherwise you probably have to seek help with the upstream project I guess.

@murgero ah thanks, pushed a fix. Both nextcloud and collabora links were broken.

@jdaviescoates Yes I still use mainly Collabora with Nextcloud and I have noticed tremendous improvements, especially since NC and Collabora have worked together to improve the integration.
However, I wouldn't say it is still quite like Google doc, or quite as fast as OnlyOffice. I tired OnlyOffice when I installed CryptPad and something about it feels more responsive than Collabora due to client rendering. It is basically just like editing on a desktop and Collabora is not quite there...but pretty close. Also we can feel that both Gdocs and OnlyOffice were designed as a collaborative editing tool whereas Collabora somewhat inherits the LO single user approach and tries to adapt it for collaboration and the result still does not feel quite as sleek....but here again it is getting much better than it used to be.
I can say that Collabora does not suffer from issues from the past, does not feel laggy and is perfectly fast enough to use while not feeling it's slow or weird. Also I do think it provides the most complete online office suit in terms of functionalities, and the best if you using open document formats.

@avatar1024 thanks we will update. The reason for it not being updated yet, is that their package repositories are usually lacking behind their release tag by a day and we have to wait for those.