No shared roster?

[Demosthenexx]

Recently upgraded to ejabberd 18, with xcauth 2.0.3 and Nextcloud 15. Got xcauth working again fine, but we have no shared roster.

% /usr/sbin/xcauth -R user domain
2019-05-09 22:49:30,845 DEBUG: Start external auth script 2.0.3 for ejabberd with endpoint: https://domain:3456/nextcloud/index.php/apps/ojsxc/ajax/externalApi.php
2019-05-09 22:49:30,846 DEBUG: Opening database connections main=/var/lib/xcauth/xcauth.sqlite3, cache=none
2019-05-09 22:49:30,851 DEBUG: Starting new HTTPS connection (1): domain
2019-05-09 22:49:30,901 DEBUG: https://domain:3456 "POST /nextcloud/index.php/apps/ojsxc/ajax/externalApi.php HTTP/1.1" 200 47
{"result":"success","data":{"sharedRoster":[]}}
2019-05-09 22:49:30,938 DEBUG: https://domain:3456 "POST /nextcloud/index.php/apps/ojsxc/ajax/externalApi.php HTTP/1.1" 200 47

Shared roster is empty. However the DB shows data:

/var/lib/xcauth
% sqlite3 xcauth.sqlite3
SQLite version 3.16.2 2017-01-06 16:32:41
Enter ".help" for usage hints.
sqlite> select * from rosterinfo;
admin@domain|admin||eabf1857b0085f396032e67c33ec5d77dc6248e20874e920bd41ee8de6d04a60|2019-05-09 19:03:09.569577
..... many more records
sqlite> select count(*) from rosterinfo;
23

From ejabberd.yml:

   mod_roster:
    versioning: false
    store_current_id: false
  mod_s2s_dialback: {}
  mod_shared_roster:
    db_type: mnesia

[MarcelWaldvogel]

This does not seem to be an issue with the xcauth side, but with the Nextcloud side.

Do you have @ in your login names? What does the Nextcloud log say?

[Demosthenexx]

No @ or unusual characters in usernames.

Can you be more clear on which log file you mean? Wouldn't a shared XMPP roster be a JSXC issue at the presentation layer?

[MarcelWaldvogel]

The log that can be viewed within the Nextcloud admin settings; e.g. /var/www/nextcloud/nextcloud.log.

Shared rosters are implemented as follows: Whenever a user logs in (auth request to xcauth, whether from JSXC app or from any other XMPP client), xcauth does the following (simplified):

1. Check in the cache whether the (encrypted) passwords match. If so, return success.
2. Ask the Nextcloud to verify the password. On success, this also returns the (Nextcloud) groups the user is in and the names of the fellow members. If it fails, return failure.
3. If ejabberdctl is not set, terminate here with success.
4. Check in the cache whether the group/name list it is the same as returned last time. If so, return success.
5. If it was changed, calculate the modifications that need to be done to the ejabberd shared_roster_groups and fire off the corresponding ejabberdctl commands.

In your xcauth -R output, Nextcloud returns an empty sharedRoster list. So, xcauth cannot tell anything to ejabberd.

BTW: I didn't ask for the most obvious yet: Your user is in at least one group, and that group also has other members?

[Demosthenexx]

On Thu, Sep 19, 2019 at 01:29:57PM -0700, Marcel Waldvogel wrote:

The log that can be viewed within the Nextcloud admin settings; e.g. /var/www/nextcloud/nextcloud.log.

I've set this to level 0 (debug) and will retest.

In your xcauth -R output, Nextcloud returns an empty sharedRoster list. So, xcauth cannot tell anything to ejabberd.

BTW: I didn't ask for the most obvious yet: Your user is in at least one group, and that group also has other members?

All users are in group public.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/jsxc/xmpp-cloud-auth/issues/79#issuecomment-533296954

[Demosthenexx]

Checking Nextcloud more, all my users are in the Public group. We are sending test messges fine across XMPP, it's just we have to manually add everyone as contacts in JSXC. I'm not seeing anything that stands out in the logs.

I am seeing successful password authentication via xcauth, and contact lookups via ojsxc.

Going back to my original post, I believe that shows the xcauth sqlite data has the group information but the -R doesn't show it. Can you help explain that?

[MarcelWaldvogel]

The hash in the rosterinfo table exists for everyone who has ever logged in. It is the hash over the JSON response, even over an empty response. The groups column is empty, matching what is returned by -R. I would expect that the rostergroups table should also be empty to reflect this.

I need the expertise from @sualko for looking into what ojsxc is doing, but he is back only in a few days.

In the meantime: What is the size of this "public" group? Which backend are you supplying the users through?

As a workaround for now, any ejabberd admin can create shared roster groups. Example 1 in the shared roster documentation solves your use case.

[Demosthenexx]

The rostergroups table has data, showing group@mydomain.org and then a list of users.

I have 20 users, this is a private installation for family. Nothing unusual.

I thought we had this working under the previous Nextcloud version, but I'll go look at the workaround you are recommending. That may be more appropriate anyway. Thanks.

[MarcelWaldvogel]

It might be that the group API inside Nextcloud has changed. @sualko will hopefully be able to look into it next week.

[sualko]

I can confirm that jsxc returns an empty roster and I will look at it asap.

[sualko]

It seams that this is another issue with Nextclouds case-sensitive usernames. Can you try the /usr/sbin/xcauth -R user domain with the correct case?

[Demosthenexx]

I think you nailed it. My users have mixed case in their names (LastFM), and using xcauth with the specific case does show the roster.

On Tue, Sep 24, 2019 at 02:15:49AM -0700, Klaus wrote:

It seams that this is another issue with Nextclouds case-sensitive usernames. Can you try the /usr/sbin/xcauth -R user domain with the correct case?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/jsxc/xmpp-cloud-auth/issues/79#issuecomment-534470119

---

(..) Russell Adams / Demosthenes Demo@Demosthenes.org /\/\ // \ Linux Powered since 1996 ( ) PGP Key Id: 0xADA00D29 ^ ^ Fingerprint: E928 A47A E032 D745 753B B8AD 36B1 68E1 ADA0 0D29

---

[sualko]

Just a little update: It seams that this has been fixed in Nextcloud between NC 15 and 17. I can reproduce it only on 15, but not on 17. I also doubt that this is something which can be fixed on our side. @MarcelWaldvogel do you have an idea?

[MarcelWaldvogel]

Besides upgrading to something newer than NC 15, I do not have any idea. As there is an upstream (Nextcloud) fix, I am closing the issue for now. Please reopen if necessary.