Open Bug 1661237 Opened 4 years ago Updated 4 years ago

CardDAV sync works only one way

Categories

(Thunderbird :: Address Book, defect)

Thunderbird 82
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: ak.bugzilla, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36 Edg/84.0.522.63

Steps to reproduce:

Connected two CardDAV address books (Google, Yahoo) to the Thunderbird address book with the built-in CardDAV functionality. Created and edited some nonsense contacts in Thunderbird as well as in web mail and synced them (right click on the address book -> syncronize).

Actual results:

Changes made in Thunderbird were synced to web mail, but web mail changes not back to Thunderbird.

Expected results:

Sync should work in both directions.

I'm going to need some more information here.

Firstly, how have you connected to Google when Google only supports OAuth authorisation, and that can only be done with code that hasn't yet landed?

I've never tested the code with Yahoo, so there may be some differences in server behaviour our code doesn't expect. Could you try debugging with the Network panel in the developer tools and report any server responses that seem suspicious?

Flags: needinfo?(ak.bugzilla)

Strange, I connected to https://www.googleapis.com/carddav/v1/principals/myname@gmail.com/lists/default/ some time ago but can't reproduce that now. Sync is still working at least one way. According to the password manager I did this connection on June 1st.

I use OAuth authorisation for my Yahoo mails, so might be the same reason. I now also tested with a Posteo account and this synced in both directions. Yahoo shows me a 400 Bad request in the Network panel. I'm not familiar with these entries:

Response headers:
HTTP/2 400 Bad Request
x-yahoo-social-host: prod4cws15.xobni.ir2.yahoo.com
access-control-expose-headers: X-Yahoo-Social-ContactsRev,X-Yahoo-Social-Host,WSSIdReissue
access-control-allow-origin: https://carddav.address.yahoo.com
access-control-allow-credentials: true
access-control-allow-methods: GET,PUT,POST,DELETE,OPTIONS
access-control-allow-headers: Origin,X-Requested-With,Content-Type,Accept,X-YahooWSSID-Authorization,x-guid,x-sc-dest-auth,x-sc-auth
y-rid: 7hn7kelfl1a9b
x-frame-options: SAMEORIGIN
servletwebservicefilter-enabled: true
content-length: 0
date: Thu, 03 Sep 2020 08:28:27 GMT
age: 0
server: ATS
referrer-policy: no-referrer-when-downgrade
strict-transport-security: max-age=15552000
expect-ct: max-age=31536000, report-uri="http://csp.yahoo.com/beacon/csp?src=yahoocom-expect-ct-report-only"
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
X-Firefox-Spdy: h2

Request headers:
REPORT /dav/xxx/Contacts/ HTTP/2 (xxx = my personal user ID)
Host: carddav.address.yahoo.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Thunderbird/82.0a1
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Depth: 1
Content-Type: text/xml
Content-Length: 150
Origin: https://carddav.address.yahoo.com
DNT: 1
Authorization: Basic YW5keV9nMTQwOTppc282bm90OQ==
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
TE: Trailers

Flags: needinfo?(ak.bugzilla)

Odd that it still appears to be working in one direction, but it shouldn't be happening in either if authorisation is the problem, and it almost certainly is. Which reminds me, I don't have bugs filed for adding OAuth support, although it's been almost ready (in the case of Google, at least) for ages.

Depends on: 1662979

I've been trying to get Yahoo! working and I've experienced the same thing – I added a contact and the server accepted it, but the server won't respond to any requests about what it has on it.

You need to log in before you can comment on or make changes to this bug.