search

jsxc / xmpp-cloud-auth

:key: Authentication hub for Nextcloud+JSXC→Prosody, ejabberd, saslauthd, Postfix
https://www.jsxc.org
MIT License
60 stars 18 forks source link

Working configs for Nextcloud user@domain accounts? #13

Closed rev138 closed 7 years ago

rev138 commented 7 years ago

I'm using v3.2.0-beta3 with NC 12.0.0 and prosody. Following the README precisely, this does not work for me, nor do I get any useful error messages. It doesn't look like the auth script is starting.

Can someone with working config please provide their complete prosody.cfg.lua and nextcloud admin settings?

Thanks

colarocker commented 7 years ago

I got the same problem with ejabberd and this auth script, it just quits with reason normal, no log-files created for the auth script.. (apparmor disabled)

sualko commented 7 years ago

@rev138 did you read the text behind the :warning:?

@colarocker please check your syslog to ensure that apparmor is properly disabled, because this is tricky.

colarocker commented 7 years ago

thanks for your reply @sualko, i installed the aa-utils, used aa-status, which replied "apparmor module is not loaded" and also checked with "sudo service apparmor status" which replied "Loaded: loaded(/etc/init.d/apparmor) Active: inactive (dead)" so i believe it's really deactivated. /http-bind/ works, correct rights for the auth script are set, it runs if i start it manually from SSH and also starts to log then but when i use it out of ejabberd it doesn't log. login from nextcloud is just loading, sometimes after 2-3 minutes it will load the main page of nextcloud, but chat isn't working. (when i stop ejabberd-service while hanging on login, it immediately goes to main-page of nextcloud) :/ do you have experience with login-format? in nextcloud i don't use the username+domain combination for login, just the username, could it be related to that? i think i'm gonna try to change it later and test it because i'm out of ideas.

sualko commented 7 years ago

@colarocker It's not clear from your post, if you checked your syslog and ejabberd log (with log level debug). With the -d flag you can also enable verbose logging for the auth script.

colarocker commented 7 years ago

@sualko i checked my syslog and didn't find any information about apparmor (using a pre-installed vserver with ubuntu 15.04, heard the first time about apparmor when trying to get xmpp-cloud-auth to work). im happy to say that i resolved the problem with the login-page. I added my email to the nextcloud user-page so i can login with username@domain, which works with ejabberd activated. i immediately get forwarded to the nextcloud mainpage. still the chat is not working. i looked through the ejabberd log and found one error and one info (they also appeared when the login didnt forward me to the mainpage):

2017-05-24 10:56:16.580 [error] <0.2796.0>@extauth:loop:130 extauth call '[<<"auth">>,<<"colarocker">>,<<"domain.de">>,<<"PASSWORD">>]' didn't receive response

2017-05-24 10:56:16.580 [info] <0.2794.0>@ejabberd_c2s:wait_for_feature_request:757 ({socket_state,ejabberd_http_bind,{http_bind,<0.2793.0>,{{0,0,0,0,0,0,0,1},37228}},ejabberd_http_bind}) Failed authentication for colarocker@domain.de$

a little bit later also this:

2017-05-24 10:56:46.592 [info] <0.2793.0>@ejabberd_http_bind:handle_info:519 Session timeout. Closing the HTTP bind session: <<"a3c18330346b89d0a209b3ba658ebc9d41a7444a">>

also, there is no added information in the xmpp-cloud-auth logs ( verbose logging is activated ) if you have any ideas, i would appreciate it :)

colarocker commented 7 years ago

ok, little update: i used my subdomain for the BOSH http-bind. this created a problem for the chat username (user@sub.domain.de). changed the domain to domain.de (chat username now user@domain.de), now i finally can login to the chat hurray. So in conclusion, you should use user@domain to login to your nextcloud, otherwise it won't work right.

colarocker commented 7 years ago

update #2; f*** my conclusion; now it's also working without user"@domain.de"; login to xmpp works now without it... chat's still not working properly, no communication possible atm. but i think i'm gonna resolve it sooner or later..

rev138 commented 7 years ago

@rev138 did you read the text behind the :warning:?

@sualko I did. There are two issues referenced

https://github.com/jsxc/ejabberd-cloud-auth/issues/1

Your comments there say it's obsolete

https://github.com/jsxc/xmpp-cloud-auth/issues/2

This says to use a custom mod_auth_external.lua, which is also included in the repo. I am using this.

I'm not trying to suggest this doesn't work, but I assume someone has a working config so I would appreciate being able to look at it to see where mine differs.

rev138 commented 7 years ago

Also, I am curious: When prosody is running, should it automatically start external_cloud.py? I don't see that running, ever.

MarcelWaldvogel commented 7 years ago

@rev138 At least on ejabberd, external_cloud.py is started at the beginning. However, if external_cloud.py crashes immediately (e.g., because the python-requests package is missing), it will not be visible.

I believe that on Prosody, it is only launched on the first login attempt.

MarcelWaldvogel commented 7 years ago

There is a new version out there, which has the "-A" test option to verify the connection script->cloud. Also, the README has been updated to reflect some of my distress when trying to get it running. Maybe some of this helps.

Carpintonto commented 7 years ago

My logs suggest external_cloud.py is working, but there is a loss in translation. running Nextcloud 12.0.0 with Prosody 0.9.10 and the custom mod_auth_external All my user names are of the form "user@example.com"

2017-06-03 20:21:16,462 INFO: Start external auth script 0.2.0 for prosody with endpoint: https://example.com/nextcloud/index.php/apps/ojsxc/ajax/externalApi.php 2017-06-03 20:21:16,462 DEBUG: Log level: INFO 2017-06-03 20:21:16,462 DEBUG: Could not decode token (maybe not a token?) 2017-06-03 20:21:16,467 INFO: Starting new HTTPS connection (1): example.com 2017-06-03 20:21:16,683 DEBUG: "POST /nextcloud/index.php/apps/ojsxc/ajax/externalApi.php HTTP/1.1" 200 None 2017-06-03 20:21:16,688 INFO: SUCCESS: Cloud says password for user@example.com@example.com is valid True

/var/log/prosody/extauth.log 2017-06-03 20:13:03,468 INFO: Start external auth script 0.2.0 for prosody with endpoint: https://example.com/nextcloud/index.php/apps/ojsxc/ajax/externalApi.php 2017-06-03 20:13:03,468 DEBUG: Log level: DEBUG 2017-06-03 20:13:03,468 DEBUG: from_prosody got %sauth:user:example.com:p4ssw0rd 2017-06-03 20:13:03,468 DEBUG: Receive operation auth 2017-06-03 20:13:03,468 DEBUG: Could not decode token (maybe not a token?) 2017-06-03 20:13:03,474 INFO: Starting new HTTPS connection (1): example.com 2017-06-03 20:13:03,774 DEBUG: "POST /nextcloud/index.php/apps/ojsxc/ajax/externalApi.php HTTP/1.1" 200 None 2017-06-03 20:13:03,781 INFO: FAILURE: Neither token nor cloud approves user user@example.com

/prosody.log Jun 03 20:13:03 mod_bosh info New BOSH session, assigned it sid '8307c091-6238-4d82-b774-0644659d29aa' Jun 03 20:13:03 example.com:auth_external warn Unable to interpret data from auth process, [41 bytes]

Nextcloud logs Warning core Login failed: 'user' (Remote IP: 'xxx.xxx.xx.xx') 2017-06-03T20:13:03-0700

I am going to mess with Prosody log levels to see exactly what the [41 bytes] is.

MarcelWaldvogel commented 7 years ago

  1. Here is an attempt at getting user@domain working: Could you please try 091d1fc together with MarcelWaldvogel/jsxc.nextcloud@e41e2a45a6331ae84d0ac16babdaf484390d7138 (putting externalApi.php into …/nextcloud/apps/ojsxc/ajax is enough)? In our installations, we do not have user@domain accounts, so forgot about that case. Sorry!

  2. Could you please let me know what those 41 bytes from prosody.log are? I currently can't imagine where they could come from (you're using -t prosody, I presume)?

Carpintonto commented 7 years ago
  1. With both new files we went backwards:

2017-06-04 14:59:51,471 INFO: Start external auth script 0.2.0+ for prosody with endpoint: https://example.com/nextcloud/index.php/apps/ojsxc/ajax/externalApi.php 2017-06-04 14:59:51,471 DEBUG: Log level: INFO 2017-06-04 14:59:51,472 DEBUG: Could not decode token (maybe not a token?) 2017-06-04 14:59:51,477 INFO: Starting new HTTPS connection (1): example.com 2017-06-04 14:59:53,202 DEBUG: "POST /nextcloud/index.php/apps/ojsxc/ajax/externalApi.php HTTP/1.1" 500 None 2017-06-04 14:59:53,206 INFO: FAILURE: Neither token nor cloud approves user user@example.com@example.com False

extauth.log was not appended after server restart and login attempt. I will try different combinations.

  1. Not getting the [41 bytes] since I toggled off legacy authentication. I will also make sure that is what makes it appear.
Carpintonto commented 7 years ago

With e41e2a4 externalApi.php Nextcloud logged Error: Function name must be a string line 101: checkPassword() I think that's a php fatal on anonymous function stringOrEmpty?

091d1fc external_cloud.py does work on cli -A options with the original externalApi.php

I am not seeing the [41 bytes] with legacy authentication disabled.

MarcelWaldvogel commented 7 years ago

Could you try 64f1e9b externalApi.php? (An old version sneaked in)

I don't have a prosody installation handy, but mod_auth_external does only seem to support SASL PLAIN. As I doubt anyone cannot support SASL PLAIN these days, legacy auth has probably not been tested and may be the reason. Do you have any causes for enabling it?

Carpintonto commented 7 years ago

legacy auth is required by another js xmpp client just to register new users. I do not need it to be enabled. I'd be glad to run 64f1e9b externalApi.php I'm GMT -8 sorry for the lags - day job is not at a computer. 64f1e9b externalApi.php works! Good job Marcel.

MarcelWaldvogel commented 7 years ago

@rev138 and @colarocker: Did you check the new instructions in the README and the new code? Does this explain things better? Or are there still open questions?

marxistvegan commented 7 years ago

So I am running into this problem too... specifically https://github.com/jsxc/xmpp-cloud-auth/issues/13#issuecomment-306071107 And maybe I am not following the user@domain instructions correctly. When i run the -I USER DOMAIN it says the user exists. But the same token error when running -A USER DOMAIN PASSWORD

I am running Debian Jessie, Prosody 0.9.7-2 and Nextcloud 12

rev138 commented 7 years ago

@MarcelWaldvogel : The -A option allows me to auth successfully. I'm starting to think the problem is with prosody and not xmpp-cloud-auth. I configured it to run a simple bash script that echos a string to a file in /tmp, but that doesn't work. It seems like prosody isn't launching the script.

MarcelWaldvogel commented 7 years ago

This is a weird issue, as there seem to be multiple cases and causes. Let me open new tickets for each of you.

MarcelWaldvogel commented 7 years ago

@sualko Thanks for merging. I hope this should fix the problem for those with ejabberd. I'm still working on the Prosody-related problem(s) in #19 and #20.

Aquariu commented 6 years ago

Dear all, I had a bizarre error while calling xcauth from Prosody, and then I realised that:

./xcauth.py -t prosody -A 'username' 'domain' 'pass' failed while ./xcauth.py -t prosody -A 'username@domain' '' 'pass' worked ok (yes, all my users are in the "user@domain.fr" way) So I dug into xcauth.py and in function auth_cloud() modified line 208 like this:

'username': username + '@' + domain,

Now Conversation can finally login. But jsxc cannot (auth fails, xcauth says "noauth")! Is there a way I can make this hack less ugly ? Is there a workaround/normal way of doing things that I just didn't see ?

Kind regards,

Olivier

MarcelWaldvogel commented 6 years ago

@Aquariu: What version of JSXC are you using? They (in theory) should all both check whether a user username@domain (tested first) or username exists. So this should not be necessary.

See e.g., ExternalApiController.php for a code snippet (from the current 3.3.0beta tree)

Aquariu commented 6 years ago

Thanks for taking the time to answer,

I had (wrongly) assumed that the last stable JSXC version (3.2.1) would be recent enough to work with xcauth. I was wrong obviously, at least for my case with usernames like emails.

So I just updated to 3.3.0 beta. and reverted my changes to xcauth.py. Server config:

Testing:

Also, I can use the Prefer mail address to loginName@xmppDomain but if my understanding is correct it's rather pointless for me as the usernames are already in this form.

I'll try to come back to the time-limited token issue later but that's not a priority at the moment.

Thanks very much for your support!

MarcelWaldvogel commented 6 years ago

Indeed, JSXC originated in a world without at signs in usernames. So there are still some rough edges there. There is an xmpp-cloud-auth update from earlier today which tries to deal with the time-limited tokens for logins with @s in them.

Some of our @-processing will change, as we finalize our thoughts and will include support for logins with @ which do not match the XMPP server domain(s).

Aquariu commented 6 years ago

Thanks for the update. In my case, emails as logins made my setup simpler as I already had a nice and tidy dovecot install and wanted to use that an auth backend for all my NC users (so that I don't have to create and manage them at more than one place).

MarcelWaldvogel commented 6 years ago

If you have an external authentication source, then the XMPP server might also authenticate against it. At least, that was the original setup for the first few years of JSXC existence before xmpp-cloud-auth arrived. Time-limited tokens (simpler web reconnect) and the Nextcloud application password (better device-management) do have some benefits, though.