Skip to content
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

Closed
landryb opened this issue Jan 28, 2020 · 14 comments
Closed

support for NC 18 #77

landryb opened this issue Jan 28, 2020 · 14 comments

Comments

@landryb
Copy link

landryb commented Jan 28, 2020

Fwiw, user_cas 1.8.0 works fine here with NC 18.0, just had to adjust appinfo.xml:

<nextcloud min-version="14" max-version="18"/>

setup with users coming from ldap, cas attributes sent by cas server, and the following app config (vars coming from ansible):

      cas_server_hostname: "{{ cas_server_hostname }}",
      cas_server_port: 443,
      cas_server_path: "/cas",
      cas_displayName_mapping: "givenName+sn",
      cas_group_mapping: "cloud",
      cas_email_mapping: "mail",
      cas_protected_groups: "admin",
      cas_access_allow_groups: "{{ nextcloud_access_role }}",
      cas_force_login: 1,
      cas_force_login_exceptions: "{{ groups['web'] | map('extract', hostvars, ['ansible_default_ipv4', 'address']) | join(',') }}",
      cas_autocreate: 1,
      cas_update_user_data: 1
@landryb
Copy link
Author

landryb commented Jan 28, 2020

actually, im not 100% sure anymore this works fine, as trying to access a webdav share via cadaver redirects me to the cas page:

> PROPFIND /remote.php/webdav/ HTTP/1.1
< HTTP/1.1 302 Found
< Location: https://cas_server/cas/login?service=https%3A%2F%2Fnextcloud_server%2Fremote.php%2Fwebdav%2F&gateway=true

feels like #57 once again but cadaver used to work fine with user_cas 1.6.1 & nc 15.. will investigate more.

@landryb
Copy link
Author

landryb commented Jan 28, 2020

or its a fallout of cec3a7b which looks vaguely related, but locally reverting the appinfo/app.php chuck doesnt fix webdav login.

@landryb
Copy link
Author

landryb commented Jan 28, 2020

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:

AFC9 .START (2020-01-28 15:38:52) phpCAS-1.3.7 ****************** [CAS.php:475]
AFC9 .=> phpCAS::client('3.0', 'xxx', 443, '/cas') [AppService.php:286]
AFC9 .|    => CAS_Client::__construct('3.0', false, 'xxx', 443, '/cas', true) [CAS.php:365]
AFC9 .|    |    Session is not authenticated [Client.php:938]
AFC9 .|    <= ''
AFC9 .<= ''
AFC9 .=> CAS_Client::handleLogoutRequests(true, array ()) [CAS.php:1298]
AFC9 .|    Not a logout request [Client.php:1733]
AFC9 .<= ''
AFC9 .=> phpCAS::setNoCasServerValidation() [AppService.php:307]
AFC9 .|    You have configured no validation of the legitimacy of the cas server. This is not recommended for production use. [CAS.php:1664]
AFC9 .<= ''
AFC9 .=> phpCAS::isAuthenticated() [UserHooks.php:151]
AFC9 .|    => CAS_Client::isAuthenticated() [CAS.php:1167]
AFC9 .|    |    => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1387]
AFC9 .|    |    |    no user found [Client.php:1629]
AFC9 .|    |    <= false
AFC9 .|    |    no ticket found [Client.php:1488]
AFC9 .|    <= false
AFC9 .<= false
AFC9 .=> phpCAS::isAuthenticated() [NextBackend.php:111]
AFC9 .|    => CAS_Client::isAuthenticated() [CAS.php:1167]
AFC9 .|    |    => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1387]
AFC9 .|    |    |    no user found [Client.php:1629]
AFC9 .|    |    <= false
AFC9 .|    |    no ticket found [Client.php:1488]
AFC9 .|    <= false
AFC9 .<= false
AFC9 .=> phpCAS::isAuthenticated() [UserHooks.php:232]
AFC9 .|    => CAS_Client::isAuthenticated() [CAS.php:1167]
AFC9 .|    |    => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1387]
AFC9 .|    |    |    no user found [Client.php:1629]
AFC9 .|    |    <= false
AFC9 .|    |    no ticket found [Client.php:1488]
AFC9 .|    <= false
AFC9 .<= false

and one for the 'broken' version with user_cas 1.8.0/phpcas 1.3.8.

F902 .START (2020-01-28 15:16:13) phpCAS-1.3.8 ****************** [CAS.php:475]
F902 .=> phpCAS::client('3.0', 'xxx', 443, '/cas') [AppService.php:293]
F902 .|    => CAS_Client::__construct('3.0', false, 'xxx', 443, '/cas', true) [CAS.php:365]
F902 .|    |    Session is not authenticated [Client.php:938]
F902 .|    <= ''
F902 .<= ''
F902 .=> CAS_Client::handleLogoutRequests(true, array ()) [CAS.php:1298]
F902 .|    Not a logout request [Client.php:1744]
F902 .<= ''
F902 .=> phpCAS::setNoCasServerValidation() [AppService.php:314]
F902 .|    You have configured no validation of the legitimacy of the cas server. This is not recommended for production use. [CAS.php:1664]
F902 .<= ''
F902 .=> phpCAS::checkAuthentication() [NextBackend.php:148]
F902 .|    => CAS_Client::checkAuthentication() [CAS.php:1100]
F902 .|    |    => CAS_Client::isAuthenticated() [Client.php:1336]
F902 .|    |    |    => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1398]
F902 .|    |    |    |    no user found [Client.php:1640]
F902 .|    |    |    <= false
F902 .|    |    |    no ticket found [Client.php:1499]
F902 .|    |    <= false
F902 .|    |    user is not authenticated (cache reset) [Client.php:1374]
F902 .|    |    => CAS_Client::redirectToCas(true) [Client.php:1375]
F902 .|    |    |    => CAS_Client::getServerLoginURL(true, false) [Client.php:1661]
F902 .|    |    |    |    => CAS_Client::getURL() [Client.php:342]
F902 .|    |    |    |    |    Final URI: https://yyy/remote.php/webdav/ [Client.php:3585]
F902 .|    |    |    |    <= 'https://yyy/remote.php/webdav/'
F902 .|    |    |    <= 'https://xxx/cas/login?service=https%3A%2F%2Fyyy%2Fremote.php%2Fwebdav%2F&gateway=true'
F902 .|    |    |    Redirect to : https://xxx/cas/login?service=https%3A%2F%2Fyyy%2Fremote.php%2Fwebdav%2F&gateway=true [Client.php:1668]
F902 .|    |    |    exit()
F902 .|    |    |    -
F902 .|    |    -
F902 .|    -

from my understanding, previously only isAuthenticated was called and it was fine if the return value was false, and now checkAuthentication is called first and fails hard the request ?

@felixrupp any idea?

@landryb
Copy link
Author

landryb commented Jan 28, 2020

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 isAuthenticated() early ?) didnt help. Guess for now i'll revert back to 1.7.4 until webdav can be fixed.

@landryb
Copy link
Author

landryb commented Jan 28, 2020

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.

@felixrupp
Copy link
Owner

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,
Felix

@felixrupp felixrupp self-assigned this Jan 28, 2020
@felixrupp felixrupp added this to the 1.8 milestone Jan 28, 2020
@felixrupp
Copy link
Owner

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:

4F3D .START (2020-01-28 20:24:03) phpCAS-1.3.8 ****************** [CAS.php:475]
4F3D .=> phpCAS::client('3.0', 'cas.thm.de', 443, '/cas') [AppService.php:293]
4F3D .|    => CAS_Client::__construct('3.0', false, 'cas.thm.de', 443, '/cas', true) [CAS.php:365]
4F3D .|    |    Session is not authenticated [Client.php:938]
4F3D .|    <= ''
4F3D .<= ''
4F3D .=> CAS_Client::handleLogoutRequests(true, array ()) [CAS.php:1298]
4F3D .|    Not a logout request [Client.php:1744]
4F3D .<= ''
4F3D .=> phpCAS::setNoCasServerValidation() [AppService.php:314]
4F3D .|    You have configured no validation of the legitimacy of the cas server. This is not recommended for production use. [CAS.php:1664]
4F3D .<= ''
4F3D .=> phpCAS::isAuthenticated() [UserHooks.php:243]
4F3D .|    => CAS_Client::isAuthenticated() [CAS.php:1167]
4F3D .|    |    => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1398]
4F3D .|    |    |    no user found [Client.php:1640]
4F3D .|    |    <= false
4F3D .|    |    no ticket found [Client.php:1499]
4F3D .|    <= false
4F3D .<= false
285A .START (2020-01-28 20:24:04) phpCAS-1.3.8 ****************** [CAS.php:475]
285A .=> phpCAS::client('3.0', 'cas.thm.de', 443, '/cas') [AppService.php:293]
285A .|    => CAS_Client::__construct('3.0', false, 'cas.thm.de', 443, '/cas', true) [CAS.php:365]
285A .|    |    Session is not authenticated [Client.php:938]
285A .|    <= ''
285A .<= ''
285A .=> CAS_Client::handleLogoutRequests(true, array ()) [CAS.php:1298]
285A .|    Not a logout request [Client.php:1744]
285A .<= ''
285A .=> phpCAS::setNoCasServerValidation() [AppService.php:314]
285A .|    You have configured no validation of the legitimacy of the cas server. This is not recommended for production use. [CAS.php:1664]
285A .<= ''
285A .=> phpCAS::isAuthenticated() [UserHooks.php:243]
285A .|    => CAS_Client::isAuthenticated() [CAS.php:1167]
285A .|    |    => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1398]
285A .|    |    |    no user found [Client.php:1640]
285A .|    |    <= false
285A .|    |    no ticket found [Client.php:1499]
285A .|    <= false
285A .<= false

@landryb
Copy link
Author

landryb commented Jan 29, 2020

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?

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 max-version in appinfo.xml to get it rolling) served by nginx and i've tested with cadaver which works fine against user_cas 1.6.1/NC 15.0 (so not #57 which only affects windows explorer)

what i dont understand from your (working) log is that phpCAS::isAuthenticated() is called in from postLogin() in UserHooks.php (and that seems to be the first call into phpCAS) while from my (failing) log it's phpCAS::checkAuthentication() which is called by checkPassword() from NextBackend.php.. so that means that checkPassword() wasnt called in your case ?

@felixrupp
Copy link
Owner

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.
If that’s the case, you can set a specific 'app-password' in Nextcloud or overwrite the user’s local password (which is a very long random generated string by default) via occ commandline interface. After you set a local password, the local login (also via WebDAV) should work as expected.

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
Felix

@landryb
Copy link
Author

landryb commented Jan 29, 2020

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 ncadmin user which is the only 'real' user, but not with users coming from ldap (which should be perfectly valid users..)

@felixrupp
Copy link
Owner

felixrupp commented Jan 29, 2020

@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
if (\phpCAS::checkAuthentication()) {
to:
if (\phpCAS::isAuthenticated()) {

and try again? Please also verify, that the regular authentication on the web interface is still working.

checkAuthentication() in most cases is the correct method to check for an auth token (ticket), but it has a fallback to redirect the user to the CAS-Server if there’s no ticket found. And that’s the problem in your case. Using isAuthenticated() removes that fallback and simply checks if there’s a ticket or not.

Thank you!

@landryb
Copy link
Author

landryb commented Jan 29, 2020

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:

BFF4 .START (2020-01-29 09:28:01) phpCAS-1.3.8 ****************** [CAS.php:475]
BFF4 .=> phpCAS::client('3.0', 'xxx', 443, '/cas') [AppService.php:293]
BFF4 .|    => CAS_Client::__construct('3.0', false, 'xxx', 443, '/cas', true) [CAS.php:365]
BFF4 .|    |    Session is not authenticated [Client.php:938]
BFF4 .|    <= ''
BFF4 .<= ''
BFF4 .=> CAS_Client::handleLogoutRequests(true, array ()) [CAS.php:1298]
BFF4 .|    Not a logout request [Client.php:1744]
BFF4 .<= ''
BFF4 .=> phpCAS::setNoCasServerValidation() [AppService.php:314]
BFF4 .|    You have configured no validation of the legitimacy of the cas server. This is not recommended for production use. [CAS.php:1664]
BFF4 .<= ''
BFF4 .=> phpCAS::isAuthenticated() [NextBackend.php:149]
BFF4 .|    => CAS_Client::isAuthenticated() [CAS.php:1167]
BFF4 .|    |    => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1398]
BFF4 .|    |    |    no user found [Client.php:1640]
BFF4 .|    |    <= false
BFF4 .|    |    no ticket found [Client.php:1499]
BFF4 .|    <= false
BFF4 .<= false
BFF4 .=> phpCAS::isAuthenticated() [UserHooks.php:243]
BFF4 .|    => CAS_Client::isAuthenticated() [CAS.php:1167]
BFF4 .|    |    => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1398]
BFF4 .|    |    |    no user found [Client.php:1640]
BFF4 .|    |    <= false
BFF4 .|    |    no ticket found [Client.php:1499]
BFF4 .|    <= false
BFF4 .<= false

and cas login via the web interface (with an user coming from ldap) also works fine. ncadmin login via the regular /login page also works.

Should the same change be also applied to lib/User/Backend.php too ? I have to admit i dont really understand the differences, if one is to be deprecated/removed or one for nextcloud and the other for owncloud..

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 :)

@felixrupp
Copy link
Owner

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,
Felix

@landryb
Copy link
Author

landryb commented Feb 10, 2020

can confirm that 1.8.1 works fine here, both web login & webdav browsing. Thanks @felixrupp !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants