search

apple / ccs-calendarserver

The Calendar and Contacts Server.
https://www.calendarserver.org
Apache License 2.0
486 stars 136 forks source link

Server doesn't handle user names witch cause URL encoding. #378

Closed macosforgebot closed 11 years ago

macosforgebot commented 11 years ago

apm@… originally submitted this as ticket:795

When creating a user name with a character which cause URL encoding of related URLs some server functionality breaks. Basic stuff works but those requests requiring clients to handle user related URLs returned to them by the server fails. Examples are sharing URLs coming from the server and sync URLs which the client afterwards try to use in multiget REPORT. The problem being that the server returns URL encoded URLs in the href elements but it doesn't accept them back.

Example (on CalendarServer trunk):

Create a user in the XML directory like:

  <user>
    <uid>e@mail.com</uid>
    <guid>e@mail.com</guid>
    <email-address>e@mail.com</email-address>
    <password>password</password>
    <name>e@mail.com</name>
  </user>

The server will now return URLs like:

 <href>/calendars/users/e%40mail.com/calendar/test.ics</href>

But it returns 404 Not Found when that URL is used in a multiget REPORT. Having the client send a non percent-encoded URL works.

It seem CalendarServer 4.2 does not return 404, but 400 Bad Request in the same scenario.

I'm not sure if it's as simple as adding unquote() to lines like

twistedcaldav/method/report_multiget_common.py:308
 resource_uri = unquote(str(href))

It seems to fix the issue for the multiget scenario described, but the problem seems to be with all scenarios where the client gets URLs from the server.

macosforgebot commented 11 years ago

@wsanchez originally submitted this as comment:1:⁠ticket:795

macosforgebot commented 11 years ago

@wsanchez originally submitted this as comment:2:⁠ticket:795

macosforgebot commented 11 years ago

apm@… originally submitted this as comment:3:⁠ticket:795

Two interesting observations related to this.

and return the principal for GUID 1234. It might be a feature, but a bit inconsistent. Shouldn't the URL be either:

/principals/__uids__/1234/

, or

/principals/users/myname/

??? And what happens when there's also a user with shortName "1234" ?

macosforgebot commented 11 years ago

@m0rgen originally submitted this as comment:4:⁠ticket:795

What form of the href are you using as the target of the REPORT? I'm asking because if the href's in your request body are using, say, the /calendars/uids/ form, the request resource has to be of the same form (it can't be /calendars/users/ form in this case). In trunk, if I use the url encoded versions for the hrefs in the request body and for the request resource, the multiget report works.

For example, I have defined this user:

<user>

<uid>uid-e@…</uid> <guid>guid-e@…</guid> <email-address>e@…</email-address> <password>password</password> <name>name-e@…</name>

</user>

Then I make a multiget REPORT:

curl --user "uid-e@…":password --basic -vvv -X REPORT -d @report-multiget http://localhost:8008/calendars/__uids__/guid-e%40mail.com/

where report-multiget contains:

<?xml version="1.0" encoding="utf-8" ?> <C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:getetag/> </D:prop> <D:href>/calendars/uids/guid-e@…/calendar/A620A1DA-03D0-4EC7-AA05-CBBD8F2FD3E8.ics</D:href> <D:href>/calendars/uids/guid-e%40mail.com/calendar/A620A1DA-03D0-4EC7-AA05-CBBD8F2FD3E8.ics</D:href> </C:calendar-multiget>

I get back this response:

<?xml version='1.0' encoding='UTF-8'?> <multistatus xmlns='DAV:'>

<response>

<href>/calendars/uids/guid-e@…/calendar/A620A1DA-03D0-4EC7-AA05-CBBD8F2FD3E8.ics</href> <status>HTTP/1.1 404 Not Found</status>

</response> <response>

<href>/calendars/uids/guid-e%40mail.com/calendar/A620A1DA-03D0-4EC7-AA05-CBBD8F2FD3E8.ics</href> <propstat>

<prop>

<getetag>"0bb70e72644e828d8de61a842a844d67"</getetag>

</prop> <status>HTTP/1.1 200 OK</status>

</propstat>

</response>

</multistatus>

Note the unencoded href got a 404 while the encoded href worked.

As for your second interesting observation, I can't reproduce that. The /principals/uids/ form doesn't use the shortName, nor does the /principals/users/ form use the GUID. On my trunk server with the above configured user, these work:

http://localhost:8008/principals/users/uid-e%40mail.com/ http://localhost:8008/principals/__uids__/guid-e%40mail.com/

but these are 404:

http://localhost:8008/principals/users/guid-e%40mail.com/ http://localhost:8008/principals/__uids__/uid-e%40mail.com/

macosforgebot commented 11 years ago

@wsanchez originally submitted this as comment:5:⁠ticket:795

This appears to work correctly.

macosforgebot commented 11 years ago

apm@… originally submitted this as comment:6:⁠ticket:795

Sorry ... I haven't had time to follow up on this, but I just discovered that what triggers this behaviour (at least in 4.2) is whether the HTTP request URI is encoded the same way as the individual <hrefs>.

Thunderbird Lightning has the weird idea that when using a HTTP calendar URL it url-encodes '@', but when using a HTTPS URL it doesn't. So doing a multiget REPORT over HTTPS from Lightning with a '@' in the request URL, but with individual <href> with '%40' (as received by an earlier req.) will trigger af lot of '400 Bad request' on CalendarServer 4.2

NB: All URL forms in this case are /calendars/users/<username>/... both in hrefs and request URI. Only difference is whether URL-encoding of the req. URI matches the way it's done in the hrefs

Isn't the problem that _isChildURI() doesn't take URL-encoding into account, but only calls path.startswith(parent) ?