-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support for NC 18 #77
Comments
actually, im not 100% sure anymore this works fine, as trying to access a webdav share via cadaver redirects me to the cas page:
feels like #57 once again but cadaver used to work fine with user_cas 1.6.1 & nc 15.. will investigate more. |
or its a fallout of cec3a7b which looks vaguely related, but locally reverting the appinfo/app.php chuck doesnt fix webdav login. |
user_cas 1.7.4 (explicitely marked as compatible with nc 18.0) allows me to access my account via webdav, so i think there's a regression here between 1.7.4 & 1.8.0. I've looked at the changelog and a potential candidate is also the phpcas 1.3.7->1.3.8 update, or b2cf74d which moved things around and potentially changed function call ordering ? I've enabled debug log and attach them here, one for the working version with user_cas 1.7.4/phpcas 1.3.7:
and one for the 'broken' version with user_cas 1.8.0/phpcas 1.3.8.
from my understanding, previously only @felixrupp any idea? |
i thought i was onto something but uncommenting https://github.com/felixrupp/user_cas/blob/master/lib/Hooks/UserHooks.php#L119 (as apparently it'd call |
and using 1.7.4 with nc 18.0 doesnt allow to login via web interface, apparently the connection with the user database doesnt work as my UID isnt found, and trying to login shows the nextcloud internal error handler, albeit debug cas log shows my user as authenticated ? either way, seems user_cas is badly broken ... bah. |
Hi @landryb Thanks for your feedback. I‘m a bit confused on what setup you‘re actually using now. Nextcloud 18 has not been supported in any version of user_cas as of now. Not in 1.8.0 and not in earlier versions. So which version of user_cas are you using, did you modify it yourself in any way? Which phpCAS version are you using? Your problem according webdav could be the same as in #57, but I cannot confirm that at the moment. I am currently in testing a few fixes and NC18 support, but with a lack of funding, I can‘t put as much time in it as I would like to. Please keep that in mind. Thank you and regards, |
Hi again @landryb I tested WebDAV access on NC18 with user_cas 1.8.0 and Cyberduck on macOs and do not have any problems connecting. My phpCAS log looks like this, which is the awaited outcome for webdav requests:
|
maybe it wasnt clear enough from my previous comments, this is user_cas 1.8.0 (with phpcas 1.3.8) on NC 18.0 (i know it's "unsupported" but i needed it so i just fixed the what i dont understand from your (working) log is that |
Hi @landryb exactly, because the NextBackend should only be used, when the user_cas app is correctly initialized (which should not be the case on WebDAV calls), otherwise NextBackend is not registered in the Nextcloud auth mechanism, and therefore not used. Also NextBackend is the user backend for CAS users only, so local/ldap/whatever user’s can not be authenticated via NextBackend. In your log, you can see, that NextBackend is used to authenticate the user (coming from the WebDAV request), but that obviously fails. I’m curious which user you try to log in via WebDAV? Are you using an account previously added by the CAS login mechanism? That would mean, the user has no local passwords and is only available to authenticate via CAS. Either way, on my test setup, the NextBackend’s checkAuthentication()-method is never called, which seems to be spooky. Can you post the full part of the Nextcloud.log according to your WebDAV request try? You need to set the loglevel to 0, so we can see all the details. Thank you for your testing and Regards |
oh btw i dont have real users, they're all in LDAP, so maybe related to #49 ? But that setup worked fine with user_cas 1.6.1 & nc 15.0. that definitely seems to be the key problem, as i can issue webdav requests with user_cas 1.8.0/nc18 using the |
@landryb Okay, that’s another story. The problem with non-local users in ownCloud/Nextcloud is, that they can not be authenticated with the local, original Database-Backend. Your use-case may have worked before, because the NextBackend was not only technically based on the Database-Backend but also had a fallback to use the Database-Backend (even if it was not really allowed by architectural design) if needed. This has changed in user_cas 1.8.0, because the solution was dirty. To try something out, could you be so kind to change the following line in your NextBackend.php file and try again? NextBackend.php: 148 and try again? Please also verify, that the regular authentication on the web interface is still working.
Thank you! |
With that oneline change webdav definitely works (with an user coming from ldap tested with curl, cadaver and gio/gvfs, and the local account ncadmin tested via curl), and the phpCAS log looks like yours:
and cas login via the web interface (with an user coming from ldap) also works fine. ncadmin login via the regular Should the same change be also applied to In any case, many thanks for looking into it and providing guidance - CAS has always looked arcane to me, and i'm really glad to have cas login working fine again - on NC 18 now :) |
Hi @landryb thanks for your feedback and good, that it works like that! Yes the change has to be applied to lib/User/Backend.php too, as this is the Backend for ownCloud installations. I had to separate both Backends a while ago, because Nextcloud changed several interfaces in another fashion than ownCloud. The fix will be in user_cas 1.8.1 coming soon! Thanks and regards, |
can confirm that 1.8.1 works fine here, both web login & webdav browsing. Thanks @felixrupp ! |
Fwiw, user_cas 1.8.0 works fine here with NC 18.0, just had to adjust appinfo.xml:
setup with users coming from ldap, cas attributes sent by cas server, and the following app config (vars coming from ansible):
The text was updated successfully, but these errors were encountered: