Working configs for Nextcloud user@domain accounts?

[rev138]

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]

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]

@rev138 did you read the text behind the ⚠️?

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

[colarocker]

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]

@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]

@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➿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]

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]

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]

@rev138 did you read the text behind the ⚠️?

@sualko I did. There are two issues referenced

#1

Your comments there say it's obsolete

#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]

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

[MarcelWaldvogel]

@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]

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]

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]

1. Here is an attempt at getting user@domain working: Could you please try 091d1fc together with MarcelWaldvogel/jsxc.nextcloud@e41e2a4 (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]

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.

2. Not getting the [41 bytes] since I toggled off legacy authentication. I will also make sure that is what makes it appear.

[Carpintonto]

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]

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]

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]

@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]

So I am running into this problem too... specifically #13 (comment)
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]

@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]

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

[MarcelWaldvogel]

@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]

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]

@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]

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:

• NC 12.0.2 on Debian 9, Prosody 0.9.12 on the same system, JSXC 3.3.0 beta
• BOSH conf: https://domain.fr:5281/http-bind/
• Nginx proxy to redirect that to https://domain.fr/http-bind/ JSXC admin page is ok with this (BOSH Server reachable.)
• Router port 5281 is open although that shouldn't be necessary (the server only has to listen to port 5281 on the loopback interface, if my understanding is correct. But port 5222 is open for outside client connections).

Testing:

• sudo -u xcauth ./xcauth.py -t prosody -A 'user-without-@domain-part' 'domain' 'pass' returns True
• sudo -u xcauth ./xcauth.py -t prosody -A 'user-with-@domain-part' '' 'pass' returns True
• sudo -u xcauth ./xcauth.py -t prosody -A 'user-with-@domain-part' 'domain' 'pass' returns True
• Conversations client on Android connects OK. This is new without my dirty change so thanks for pointing me to the 3.3.0 beta JSXC version.
• JSXC on my NC instance now connects ok either with "user-without@domain" or with the complete username. I had to uncheck the Time-limited Token thing, though because with it xcauth.py would invariably Timeout on trying, like this;

2017-08-17 16:16:00,016 WARNING: An error occured during the request to https://domain.fr/index.php/apps/ojsxc/ajax/externalApi.php for domain domain.fr: HTTPSConnectionPool(host='domain.fr', port=443): Read timed out. (read timeout=10)
2017-08-17 16:16:00,017 INFO: UNREACHABLE: Cache says password for user@domain.fr is False

this only happens when checking the Timelimited token options on the JSXC admin page

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]

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]

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]

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.