Server: Can't share calendar with users / groups if name contains spaces or umlauts

[charlessteiner]

Steps to reproduce

1. create a user with a space in the username
2. attempt to share a calendar event with user from step 1
3. event doesn't create

Expected behaviour

Tell us what should happen
Create event with users with space in username or prohibit users with a space in the username from being created. Documentation does state that "Login names may contain letters (a-z, A-Z), numbers (0-9), dashes (-), underscores (_), periods (.) and at signs (@)"

Actual behaviour

Tell us what happens instead
spaces in usernames are accepted and shared events with such a user fail

Server configuration

CentOS Linux release 7.5.1804
Operating system: CentOS Linux release 7.5.1804

Web server: Apache/2.4.6

Database:mysql Ver 15.1 Distrib 5.5.60-MariaDB, for Linux (x86_64) using readline 5.1

*PHP version: *PHP 7.2.11 (cli)

Server version: (see your admin page) Nextcloud 15.0.5

Calendar version: (see the apps page) 1.6.4

Updated from an older installed version or fresh install:
Fresh, and duplicated the error on a second fresh
Signing status (ownCloud/Nextcloud 9.0 and above):

Login as admin user into your cloud and access
http://example.com/index.php/settings/integrity/failed
paste the results here.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your instance's installation folder

Nextcloud configuration:

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your instance's installation folder

or

Insert your config.php content here
Make sure to remove all sensitive content such as passwords. (e.g. database password, passwordsalt, secret, smtp password, …)

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

LDAP configuration (delete this part if not used)

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your instance's installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Be sure to replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser:

Operating system:

CalDAV-clients:

Logs

Web server error log

Insert your webserver log here

Log file (data/nextcloud.log)

Insert your nextcloud.log file here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) ...

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[stefan-muc]

Just a question: Do you have this setting enabled?
Admin -> Settings -> Sharing ->
[x] Restrict users to only share with users in their groups

I thought I have a same problem as you (couldn't share with a group that included a space in the name), but it turned out that this setting caused the problems - I haven't been member of this group, so I couldn't share with this group.

[der-Daniel]

I did some debugging.
First thing:

https://github.com/nextcloud/server/blob/12bdb95c1a40170652570decef7f466e4b97aa65/apps/dav/lib/DAV/Sharing/Backend.php#L109-L113

compares the group id with the name part of the URI.

Example:
group id: Test Group
uri: principals/groups/Test%20Group

then Test%20Group is compared to the Test Group.

replacing it with e.g.

($principal[1] === 'groups' && !$this->groupManager->groupExists(str_replace("%20", " ", $principal[2])))) {

fixes the issue of saving the share to the database.

So, in general, we need to e.g. modify groupExists to use the url decoded version of $principal[2].

But still the other users in the group are not able to see the calendar in their view.
There must be something similar when retrieving the calendar.

[tcitworld]

@der-Daniel You can use urldecode($principal[2]) instead of simply str_replaceing the %20s.

[der-Daniel]

@tcitworld I know I know :smile: This was more about digging into it.

[der-Daniel]

Ok I spend like 5 hours in the backend, only to find out that it was a decoding issue in the front end of the calendar.

Check https://github.com/nextcloud/calendar/pull/1985

[georgehrke]

@der-Daniel Please see my comment in https://github.com/nextcloud/calendar/pull/1985#issuecomment-586738183.
I'm happy to assist in debugging this in the server.

[der-Daniel]

As far as I can tell, my my fix in the front end resolve this bug.
I also first looked into the backend.
The backend is fine.

I am able to share the cal with groups containing whitespace and umlauts.

What makes you think the backend is buggy?

[der-Daniel]

Take a look at the contacts app where this bug is not occurring.
I compare the share function in vue and the calendar app is missing the uri decode.

Then it is working properly.

[georgehrke]

Please check the response of the principal property search, as I described in https://github.com/nextcloud/calendar/pull/1985#issuecomment-586738183:

The contents of d:href is /remote.php/dav/principals/groups/group%20with%20space/.
We are just taking the value of d:href and putting it into a oc:invite block.

So there are two possible solutions to this:

• stop encoding the path like that in d:href.
• make the server accept encoded paths for an oc:invite block. (preferred one from my pov)

My point here is just that as a CalDAV client (which the Calendar app is), I'm expecting to just reuse properties i get from the server without having to encode them.

@rullzer @icewind1991 This is the issue I mentioned two weeks ago before my vacation.

[der-Daniel]

Ahh that's why you called it hot fix. Nice. :smile:

Tbh, when I digged into it I thought the fix would involve a more reasonable group id. As the group id in the database is an unnormalized string with umlate / : whitespace and so on.

The urlencode problem is a problem of responsibilities. If it is the responsibility of the backend to accept URL encoded and non encoded string, otherwise the front end should stick to what the backend expects.

But you have a valid point. This is just a hot fix.

[der-Daniel]

Will this hot fix make it into production anytime soon. As this fix is also used in the contacts app, I would really appreciate if this fix can be used until the backend is reworked.

See here:

https://github.com/nextcloud/contacts/blob/7724fb3c9bdedf7b8fee61967adbd8db78834793/src/components/Settings/SettingsAddressbookShare.vue#L98-103

Because as of now, I am unable to share calendars in the nextcloud installation of my sports club :|

[georgehrke]

Also cc @raimund-schluessler @skjnldsv about what they would consider the expected behaviour here.

[raimund-schluessler]

My point here is just that as a CalDAV client (which the Calendar app is), I'm expecting to just reuse properties i get from the server without having to encode them.

This sounds about right.
Tbh. I just adjusted the sharing code from the Contacts app for the Tasks app, that's why it is encoded there as well.

I am fine with fixing it in server. But as soon was we change it in the server, we will break Contacts and Tasks. So we have to release adjusted versions at the same time. Since it will probably take time to release a fixed server version, how about hot-fixing it in Calendar, and adjust Calendar, Contacts and Tasks once the fix is in server?

[georgehrke]

Okay, it probably makes most sense to fix it in the server with 19 and just add a version check in the contacts / calendar / tasks app to see whether to encode it yourself or not.

[tcitworld]

stop encoding the path like that in d:href.

If I read RFC 4918 correctly it should always be encoded.

Note that even though the server may be storing the member resource internally as 'a test', it has to be percent-encoded when used inside a URI reference (see Section 2.1 of [RFC3986]). Also note that a legal URI may still contain characters that need to be escaped within XML character data, such as the ampersand character.

---

But as soon was we change it in the server, we will break Contacts and Tasks.

Why ? urldecode('group%20with%20space') === urldecode('group with space')

[georgehrke]

Why ? urldecode('group%20with%20space') === urldecode('group with space')

But we also allow % in group names ...
So you can't tell if %20 is an encoded space or the result of a decoded %2520

[der-Daniel]

This is why I mentioned that the group id needs to be properly normalized in the database. The comparison done in the back end is basically a plain old string equals on any strings.

An integer or a uuid may be a better fit. :thinking:

[georgehrke]

An integer or a uuid may be a better fit. 🤔

Yes, ideally. But that's easier said than done if you already have millions of instances out there where people use all kind of weird characters in userid / groupids. Migrating to numerical user and group ids would involve touching at least half the database tables we have.

[der-Daniel]

Yes, this will be very tricky :unamused:

From the top of my hand:

As group names need to be unique maybe, one can transform them into string based uuid like ceda14f0-8508-412b-a794-4d8a9d348b02 using a hash or other deterministic functions during a migration step iff the group id does not match the uuid pattern.

[georgehrke]

We implemented a fix in the calendar for now. Proper fix would still include fixing the issues mentioned further above.

Putting into backlog for now.

[caribouW3]

Hi,
We seem to have a somewhat similar issue when trying to share a calendar with a group (mapped from LDAP) which has a '/' in its name. It seems that string normalization for the field owncloud_name in table oc_ldap_group_mapping could be a solution. Should I open a new issue for this one?

[skjnldsv]

So there are two possible solutions to this:

• stop encoding the path like that in d:href.

For me this is the way to go

[skjnldsv]

Found it, finally!
https://github.com/sabre-io/dav/commit/03fb8ed6d5656c68a7d87f8d07f8c3e15da4812c#diff-143c04617d0235612a5f380189c9b421aca777627b8dbc504179067bf29be16fR125
https://github.com/sabre-io/dav/pull/719

Related https://github.com/owncloud/core/issues/33594
cc @PVince81