N
So if you have Nextcloud installed with Cloudron usermanagement, then the app package would install user_oidc plugin and also configure it accordingly. A new installation works fine with Cloudron 9 and also an update instance here looks ok. So maybe some other plugin might interfere here?
Have you seen any errors anywhere? Maybe login with the nextcloud built-in admin account, which is not using openid to get to see errors within nextcloud admin panel.
You can select all and if the top most are not the ones you are looking for, I guess you can deselect those in the dropdown, which will push the next ones up?
Maybe some task manager like list of all is more what you are looking for, instead of cramming all this into the graph tooltip?
@fanvyr we also try to keep dependency on shiny upstream projects as low as possible, even if they may offer great benefits, those quickly become a time sink and risk, since those frameworks move fast and often are not aligned with our goals or timeframe (this is not a critique but just different goals).
Also since we are into it for the long run and with self-hosting it is much harder to push out updates for fixes to servers we don't even have access to by design, compared to a "saas git push" style for a quick hotfix, we take different decisions here. We are slowly trying to reduce dependency on npm packages overall also, given the history (leftpad was only the wakeup call). Alone nuxt for example would bring in 737 dependencies from npm. Such amounts are impossible to vet and almost everyone just banks on someone in the community will keep an eye on them...Already choosing vuejs was a tough call.
We also have to see what this "hardened" in the end really means. Already we have a base image from a well known Ubuntu state and unlike with many upstream docker images we are not blindly updating those base layers during a rebuild, which could potentially pull in malicious broken packages.
If at all, I would be lots more worried about the actual apps, which pull in GBs of modules from like npm (looking at those nextjs apps...)
Thanks for reporting! This was an oversight and is now fixed for next release https://git.cloudron.io/platform/box/-/commit/a2dd45fd69d3174b1cbac15c70bd075105dc07a1
So currently the login flow pages are served up with content security policy headers to not allow being embedded in another domain/origin. The reason for this is to prevent clickjacking attacks and was explicitly done that way.
I guess for this we would need a csp setting for the OpenID provider where one can allow specific domains/origins.
This seems to be the same as https://forum.cloudron.io/topic/14497/cloudron-auth-support-doesn-t-seem-to-work/6
I thought we had fixed that with the other auth module. @james do you remember?
Great you found a solution before I even got to read the thread 
And thanks for sharing it in detail here for others also!
That only shows up when rsync (maybe you use tarball?) is used as the storage format and the storage backend is a filesystem or mountpoint (which for sshfs it is).
Yeah not too sure myself then. So the stack trace mentiones "ep_comments_page" have you tried to disable this temporarily?
Were any other configs changed which may affect this?
@timconsidine make sure to check the "hardlink" option for the backup site. This drastically improves performance after the first full backup run since we have optimized that code to create the hardlinks remotely via ssh.
Not sure within which context this thread is started, though but we have made it two independent packages, if that is what you refer to.
Publicly listed is only the new version though, but the old one remains installable for restore and migration purposes.
Glad to hear it worked out well. Since you mentioned clouDNS, maybe worth looking into that feature request at some point soon, they seem to have a solid api in place.
We have fixed both the selecting/refresh bug as well as the sorting and readability on the graph hover overlays with 9.0.15
That would likely be the fix. Just requires the backup/restore code to keep track of those and restore them accordingly. Given that this is the only app relying on this, it is not on our immediate task list though.
Currently v2 is in our ci pipeline. But as you all mentioned here, it has various breaking changes, so we will take that slowly and yes at least it will be a major package version update, so will require manual intervention to update.
