CalDAV does not synchronize with Nextcloud if network.cookie.same-site.enabled is true

NEW
Unassigned

Status

--
major
6 months ago
4 days ago

People

(Reporter: bugzilla.mozilla.org, Unassigned, NeedInfo)

Tracking

({regression})

Lightning 6.2
regression

Details

User Story

Workaround 
===========

* set pref network.cookie.same-site.enabled to false

Attachments

(8 attachments)

(Reporter)

Description

6 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180605171542

Steps to reproduce:

install Thunderbird 60 Beta 7 (lightning 6.2)
start Thunderbird
cancel mailconfig
open calendar-tab
in sidebar - rightclick new calendar 
* on network, -> next
* caldav and entered URL, -> next
* entered name, -> next, -> ready
* entered credentials, -> ok



Actual results:

calendar on the sidebar is created
no calendar-entrys from caldav were syncronised
no error-message is shown



Expected results:

calendar-entrys from caldav should be syncronised (works in TB 52.8.0)
in error-case show error-message
(Reporter)

Comment 1

6 months ago
caldav calendar does not synchronize in Thunderbird 60 Beta 8 (lightning 6.2)
Component: Untriaged → Provider: CalDAV
Product: Thunderbird → Calendar
Version: 60 → Lightning 6.2
(Reporter)

Updated

6 months ago
Summary: caldav calendar does not synchronize in Thunderbird 60 Beta 7 with Lightning 6.2 → caldav calendar does not synchronize in Thunderbird 60 Beta 8 with Lightning 6.2

Comment 2

6 months ago
I think this also could be linked to bug 1468755

Error console is giving me a Status 503, on tb-stable the same caldav and carddav-links (as in bug 1468755) are working without any problems.

Updated

6 months ago
Duplicate of this bug: 1471183

Comment 4

6 months ago
Bug still remains on latest upcoming Beta release
http://ftp.mozilla.org/pub/thunderbird/releases/60.0b9/
(Reporter)

Comment 5

6 months ago
Furthermore I tested the import of an ics calendar:

https://www.ferienwiki.de/exports/feiertage/2018/de/niedersachsen

On TB 52 everything syncs, on TB 60 nothing happens after creating the new network-based calendar.

This seems to be a general import-problem.
Component: Provider: CalDAV → Import and Export
(Reporter)

Updated

6 months ago
Severity: normal → major
Component: Import and Export → Lightning Only
Summary: caldav calendar does not synchronize in Thunderbird 60 Beta 8 with Lightning 6.2 → network-calendar does not synchronize in Thunderbird 60 Beta 9 with Lightning 6.2

Comment 6

6 months ago
CardDAV has the same problem.
Trying to create a new addressbook under CardBook results in the following error messages.
Sorry that these are in German, but I think you will understand them anyway.

2018.06.27 09:48:59:134 : Validation module: Überprüfe ohne Suchauftrag auf https://nextcloudurl/remote.php/dav/addressbooks/users/username/contacts/ …
2018.06.27 09:48:59:252 : Validation module: Synchronisation fehlgeschlagen (Schritt: validateWithoutDiscovery, URL: https://nextcloudurl/remote.php/dav/addressbooks/users/username/contacts/, Status: 503)
2018.06.27 09:49:00:157 : Validation module: Discovery-Phase 1 auf https://nextcloudurl/remote.php/dav/addressbooks/users/username/contacts/.well-known/carddav …
2018.06.27 09:49:00:237 : Validation module: Synchronisation fehlgeschlagen (Schritt: discoverPhase1, URL: https://nextcloudurl/remote.php/dav/addressbooks/users/username/contacts/.well-known/carddav, Status: 503)
2018.06.27 09:49:01:146 : Validation module: Überprüfe ohne Suchauftrag auf https://nextcloudurl/remote.php/dav/addressbooks/username …
2018.06.27 09:49:01:227 : Validation module: Synchronisation fehlgeschlagen (Schritt: validateWithoutDiscovery, URL: https://nextcloudurl/remote.php/dav/addressbooks/username, Status: 503)

As in Lightning using a caldav calendar, error 503 is thrown.

I don't know if it is helpful, but I'm using a let's encrypt certificate on our Nextcloud Server.
Perhaps this might have something to do with this bug?

Comment 7

6 months ago
No, seems not to be SSL related.
Tried the same without SSL and the error stays the same.

Comment 8

6 months ago
I can not reproduce this - Thunderbird Beta 60.0b9 - Lightning 6.2 - New User Profile
Took longer than expected to sync, but it eventually did for me.

Comment 9

6 months ago
Created attachment 8988389 [details]
TB60-profile-bug1468912.7z

Profile for Thunderbird 60.0 beta 9

The 7zip archive contains the whole profile to test the things described in this bug report.
It also contains the file Nexcloud.login.txt which includes the URL and login credentials to our server for review of one of the developers

The archive is password protected.
I will give you the password if you send an email to my email account.

Comment 10

6 months ago
Florian, could you please change the fields product and component to something that better describes the bug.
In fact this bug is not only related to lightning as you can see from my test with cardbook addon.
It must have something to do with a core component in Thunderbird itself that deals with network connections.

So, perhaps you can change the field product to Thunderbird and the field component to something that is network related?
(Reporter)

Comment 11

6 months ago
David Ross: I tried it again, now I can import an ics calendar.
I can't say exactly what it was.

Unfortunately I cannot edit comment 5.


egal8888: There are no network related entries there, so I choosed general.
Component: Lightning Only → General
Product: Calendar → Thunderbird
Summary: network-calendar does not synchronize in Thunderbird 60 Beta 9 with Lightning 6.2 → caldav-calendar does not synchronize in Thunderbird 60 Beta 9 with Lightning 6.2
Version: Lightning 6.2 → 60

Comment 12

6 months ago
(In reply to Florian from comment #11)
> David Ross: I tried it again, now I can import an ics calendar.
> I can't say exactly what it was.

I can confirm that importing an ics calendar works in Lightning.
But, as already stated, the imported events will not be synchronized to nextcloud server.

> egal8888: There are no network related entries there, so I choosed general.

Thanks anyway for changing.

Comment 13

6 months ago
Apache log gives the following results while starting Thunderbird:

for Thunderbird 52.8.0:
46.82.42.227 - - [28/Jun/2018:14:31:42 +0200] "PROPFIND /remote.php/dav/calendars/test60/personal/ HTTP/1.1" 401 557 "-" "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Lightning/5.4.8"
46.82.42.227 - - [28/Jun/2018:14:31:43 +0200] "PROPFIND /remote.php/dav/calendars/test60/personal/ HTTP/1.1" 207 1740 "-" "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Lightning/5.4.8"
46.82.42.227 - - [28/Jun/2018:14:31:43 +0200] "OPTIONS /remote.php/dav/calendars/test60/ HTTP/1.1" 401 557 "-" "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Lightning/5.4.8"
46.82.42.227 - - [28/Jun/2018:14:31:43 +0200] "OPTIONS /remote.php/dav/calendars/test60/ HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Lightning/5.4.8"
46.82.42.227 - - [28/Jun/2018:14:31:43 +0200] "PROPFIND /remote.php/dav/principals/users/test60/ HTTP/1.1" 401 557 "-" "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Lightning/5.4.8"
46.82.42.227 - - [28/Jun/2018:14:31:43 +0200] "PROPFIND /remote.php/dav/principals/users/test60/ HTTP/1.1" 207 926 "-" "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Lightning/5.4.8"
46.82.42.227 - - [28/Jun/2018:14:31:43 +0200] "REPORT /remote.php/dav/calendars/test60/personal/ HTTP/1.1" 207 312 "-" "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Lightning/5.4.8"

As you can see, the server first answers with status code 401 and therefor sends an WWW-Authenticate header field to the client. The client sends the required credentials back to the server and logs in while getting response code 207.

for Thunderbird 60.0b9:

46.82.42.227 - - [28/Jun/2018:14:40:56 +0200] "PROPFIND /remote.php/dav/calendars/test60/personal/ HTTP/1.1" 401 557 "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Thunderbird/60.0 Lightning/6.2"
46.82.42.227 - - [28/Jun/2018:14:40:56 +0200] "PROPFIND /remote.php/dav/calendars/test60/personal/ HTTP/1.1" 503 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Thunderbird/60.0 Lightning/6.2"

As in section above the server first answers with status code 401 and therefor also sends the WWW-Auhtenticate header field to the client. But different to Thunderbird release version 52.8.0 the beta version seems to misinterprete the WWW-Authenticate header field and does not send the right credentials or otherwise does not send any credentials, or it sends another false answer flag, that makes the server responding with code 503.

The error console in Thunderbird 60.0b9 throws the following error:

Lightning:[calCachedCalendar] replay action failed: null, uri=https://test60:password@nextcloudurl/remote.php/dav/calendars/test60/personal/, result=2147500037, operation=[xpconnect wrapped calIOperation]
calCachedCalendar.js:330
(Reporter)

Comment 14

5 months ago
(In reply to David Ross from comment #8)
> I can not reproduce this - Thunderbird Beta 60.0b9 - Lightning 6.2 - New
> User Profile
> Took longer than expected to sync, but it eventually did for me.

Did your comment refer to the ics- or the caldav sync?
(ics-sync is actualy working, caldav- respectively carddav-sync are problematic)

Comment 15

5 months ago
Owncloud 7.0.4 does not run into the described issue.

That's why it might be, that the bug is not Thunderbird related.

I opened bug report for Nextcloud: https://github.com/nextcloud/server/issues/10134
(Reporter)

Comment 16

5 months ago
I looked at some other versions of (own/next)clouds:

I can confirm a working ownCloud 10.0.2.
I can confirm a not working Nextcloud 11.0.3 and nextcloud 12.0.9.
Summary: caldav-calendar does not synchronize in Thunderbird 60 Beta 9 with Lightning 6.2 → caldav/carddav does not synchronize with nextcloud in Thunderbird 60 Beta 9 with Lightning 6.2

Comment 17

5 months ago
We might be investigating the same issue here: https://gitlab.com/CardBook/CardBook/issues/306 and https://bugzilla.mozilla.org/show_bug.cgi?id=1468755

Could you confirm that TB60 beta 4 did not have the issue, while beta 5 and following have it? (you can find these versions here: https://filehippo.com/fr/download_thunderbird/history/
(Reporter)

Comment 18

5 months ago
I can confirm:
- Beta 4 syncs caldav (works)
- Beta 5 does not sync (-> actual issue)
Summary: caldav/carddav does not synchronize with nextcloud in Thunderbird 60 Beta 9 with Lightning 6.2 → caldav/carddav does not synchronize with nextcloud in Thunderbird 60 Beta 5 and up
(Reporter)

Comment 19

5 months ago
(In reply to Sisim Biva from comment #17)
> We might be investigating the same issue here:
> https://gitlab.com/CardBook/CardBook/issues/306 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1468755

Should a bug be closed as a duplicate?
(the other should be adjusted accordingly to both)

Comment 20

5 months ago
Anything we can investigate in TB here?
Flags: needinfo?(geoff)
(Reporter)

Comment 21

5 months ago
(In reply to Jorg K (GMT+2) from comment #20)
> Anything we can investigate in TB here?

From Thunderbird 60 Beta 5 the DAV sync with nextcloud is broken.
(Bug 1468755 for CardDAV, this one for CalDAV)

Where can I find the Changelog Beta 4 -> Beta 5?

Comment 23

5 months ago
Sadly that's not right. TB is also built from the mozilla-beta repository and that will have had changes between those two betas. I tried to answer the question in bug 1468755 comment #6:
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?changeset=481fea2011e6
https://hg.mozilla.org/releases/mozilla-beta/rev/3b208a6419c5
(Reporter)

Comment 24

5 months ago
I have tested several (own|next)cloud versions: 
From the release of Nextcloud, with the first version 9.0.50, Thunderbird 60 Beta 5+ no longer synchronizes.
The first 9er Owncloud version 9.0.2 synchronizes with Thunderbird 60 Beta 5 (installation problems with 9.0.0 and 9.0.1) 

I don't know which exact version of owncloud has been forked.

The only perspective seems to be a detailed logging in Apache with.... 
- Thunderbird 60 Beta 4 
- Thunderbird 60 Beta 5 

with owncloud and nextcloud.

Comment 25

5 months ago
(In reply to Florian from comment #19)

> Should a bug be closed as a duplicate?

@admins: please decide where you prefer to follow up this bug, I don't really care ;) and unfortunately, I'm not skilled enough to help more here :(
(Reporter)

Comment 26

5 months ago
Created attachment 8991262 [details]
nextcloud-sync - Apache2 error.log with loglevel trace8
(Reporter)

Comment 27

5 months ago
Created attachment 8991263 [details]
owncloud-sync - Apache2 error.log with loglevel trace8
(Reporter)

Comment 28

5 months ago
(In reply to Norbert from comment #13)
> Apache log gives the following results while starting Thunderbird:

I added apache2 log files with loglevel trace8, each for:
- nextcloud sync (not working)
- owncloud sync (working)

I also lack background knowledge about the process of the webdav-protocol.


(In reply to Sisim Biva from comment #25)
> @admins: please decide where you prefer to follow up this bug, I don't
> really care ;) and unfortunately, I'm not skilled enough to help more here :(
I do not care, too.

Updated

5 months ago
Duplicate of this bug: 1468755

Comment 30

5 months ago
(In reply to Jorg K (GMT+2) from comment #20)
> Anything we can investigate in TB here?

Did you make progress on this bug? Isn't it preventing the release of TB60?

Comment 31

5 months ago
The person working on Calendar is on leave and will return next week.
Component: General → Provider: CalDAV
Product: Thunderbird → Calendar
Version: 60 → Lightning 6.2
@Philipp Kewisch
Issue is not only related to CalDav but also to CardDav as mentioned in the subject of this issue.

Since Thunderbird Beta 60.5 I can no longer sync Calendars (Lightning) and Adressbooks (CardBook) with my Nextcloud server. The problem description "PROPFIND" results in 503 is the same in both cases.

Updated

5 months ago
Keywords: regression, regressionwindow-wanted

Comment 33

5 months ago
This is not a general issue, but seems limited to nextcloud, since it was already reported to work with owncloud 10 and it does as well with my davical test server and there seem to be no duplicates for other calendar servers atm.

And this is not a Lightning code issue - it seems to be a cookie handling issue of the network code or the nextcloud server. For the following, please also have a look at the already attached log file in attachment 8991262 [details].

The nextcloud server sets different cookies in the response to the first (Set-Cookie header), unauthorized propfind request in the log file. TB (resp. the network code) now sets the Cookie header mentioning these cookies in the second request along with the Authorization header. With this setup, the request fails and you receive the observed 503 response.

If you resend this request with just the Cookie header dropped (you can use devtool to do so, cURL or whatever you like to send it manually), it is succesful and you receive a 207 response code.

Since you can control the cookie management in TB, there is also a workaround for this issue: disable accpting cookies at all (not sure whther this might cause oauth problems) or at least and preferably for the nextcloud server (data protection setting in TB options). After doing so, a resync of the calendar will be immediately successful.

For everybody who wants to test/verify it, you can abtain a temporary instance of nextcloud at https://demo.nextcloud.com - I used that also to verify the above.

That said, it's probalbly a good idea to point the nextcloud guys to this, so they can check/fix their cookie handling. Norbert/Florian, since you already filed a bug there, can you do this?

And maybe there have been some changes in the Mozilla network code, too, since the above report mentioned this to be a non-issue before b5 (which I can confirm at least for ESR52), although the described handling doesn't look wrong to me. Philipp/Jörg/Geoff, do you have somebody from the network team who could take a look?

Comment 34

5 months ago
Honza Bambas (:mayhemer) sometimes helps with TB issues.
Flags: needinfo?(honzab.moz)

Comment 35

5 months ago
Nextcloud issue updated and support asked to NC's developer: https://github.com/nextcloud/server/issues/10134#issuecomment-404960656
(In reply to [:MakeMyDay] from comment #33)
> And maybe there have been some changes in the Mozilla network code, too,
> since the above report mentioned this to be a non-issue before b5 (which I
> can confirm at least for ESR52), although the described handling doesn't
> look wrong to me. Philipp/Jörg/Geoff, do you have somebody from the network
> team who could take a look?

Could you run the same test in 52/60b4 and see if/how it handles the cookies differently?
Flags: needinfo?(geoff) → needinfo?(makemyday)
Oops, wrong person.
Flags: needinfo?(makemyday) → needinfo?(bugzilla.mozilla.org)
(Reporter)

Comment 38

5 months ago
Created attachment 8992145 [details]
TB52 nextcloud-sync - Apache2 error.log with loglevel trace8
Flags: needinfo?(bugzilla.mozilla.org)
(Reporter)

Comment 39

5 months ago
Created attachment 8992147 [details]
TB52 owncloud-sync - Apache2 error.log with loglevel trace8
(Reporter)

Comment 40

5 months ago
Created attachment 8992148 [details]
TB60B4 nextcloud-sync - Apache2 error.log with loglevel trace8
(Reporter)

Comment 41

5 months ago
Created attachment 8992149 [details]
60B4 owncloud-Sync apache2 error.log with loglevel trace8

Comment 42

5 months ago
Thanks for providing the additional logs.

From the header of the 401 response to the inital request in b5

> Date: Tue, 10 Jul 2018 13:10:18 GMT
> Server: Apache/2.4.18 (Ubuntu)
> Set-Cookie: oc21jzsxmqti=tt2e6o21i5jjsto9b62jpkg8v0; path=/nextcloud; HttpOnly
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> Cache-Control: no-store, no-cache, must-revalidate
> Pragma: no-cache
> Set-Cookie: oc_sessionPassphrase=wcVw6Ewhlzza1KwZmiV2YR0uNd68ZwfRYGWqofRJg5evnfHTtI4ZWeoVI7US9JAIS0jxylG7HEUoygtRNjqvt8StxqV2Ln%2FjLCbgd6Ijya8WGxt%2Fh9KKqgEOHg9ganx%2F; path=/nextcloud; HttpOnly
> Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *
> Set-Cookie: nc_sameSiteCookielax=true; path=/nextcloud; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
> Set-Cookie: nc_sameSiteCookiestrict=true; path=/nextcloud; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
> WWW-Authenticate: Basic realm=\\"sabre/dav\\"
> WWW-Authenticate: Basic realm=\\"sabre/dav\\"
> X-Content-Type-Options: nosniff
> X-XSS-Protection: 1; mode=block
> X-Robots-Tag: none
> X-Frame-Options: SAMEORIGIN
> X-Download-Options: noopen
> X-Permitted-Cross-Domain-Policies: none
> Content-Length: 414
> Keep-Alive: timeout=5, max=100
> Connection: Keep-Alive
> Content-Type: application/xml; charset=utf-8

the two nc_sameSiteCookie* cookies are not submitted when doing the follow-up request

> Host: 192.168.179.126
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 Lightning/6.2b5
> Accept: text/xml
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Accept-Charset: utf-8,*;q=0.1
> Content-Length: 306
> Content-Type: text/xml; charset=utf-8
> Depth: 0
> Connection: keep-alive
> Pragma: no-cache
> Cache-Control: no-cache
> Authorization: Basic YWRtaW46UGEkJHcwcmQ=
> Cookie: oc21jzsxmqti=tt2e6o21i5jjsto9b62jpkg8v0; oc_sessionPassphrase=wcVw6Ewhlzza1KwZmiV2YR0uNd68ZwfRYGWqofRJg5evnfHTtI4ZWeoVI7US9JAIS0jxylG7HEUoygtRNjqvt8StxqV2Ln%2FjLCbgd6Ijya8WGxt%2Fh9KKqgEOHg9ganx%2F

but were with 52 or b4:

> Cookie: oc21jzsxmqti=f6r055r9oljbelvs6l7ftjqdt1; oc_sessionPassphrase=%2FiSnxtYRIBxMVMfxyR1Mz5da12fRXozVzsWez01JWUXbosuKNNR06RV06O0RBVhneqdBinjWQr1RANhq8KwWVe0S%2FufbR7sV%2BhB8A3lW%2Fj8Wktl8sJm6KPrZEjoG89Nl; nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true

(the tokens of the first two cookies are of cause expecetdly different here)

This may produce an unexpected situation for the server.

@mayhemer: do have an idea why this could happen?
Status: UNCONFIRMED → NEW
Ever confirmed: true
You could also try flipping the pref network.cookie.same-site.enabled to false. I'm not sure of the state of this feature when it landed on our beta branch, so hopefully just disabling it will improve things.
(Reporter)

Comment 44

5 months ago
Created attachment 8992161 [details]
TB60B10 - nextcloud-sync - pref network.cookie.same-site.enabled set to false - apache2 error.log with loglevel trace8
(Reporter)

Comment 45

5 months ago
I can confirm a working TB60B10 with pref network.cookie.same-site.enabled set to false, see log-file.

Comment 46

5 months ago
For the record:
Pref network.cookie.same-site.enabled was introduced at https://hg.mozilla.org/mozilla-central/rev/38a419def0a7#l5.12 in bug 1452699. That bug landed on mozilla61 and was uplifted/backported to mozilla60.

We merged it into the Thunderbird branch at https://hg.mozilla.org/releases/mozilla-beta/rev/3b208a6419c5#l397.31 for TB 60 beta 5.

You'd have to ask the author/reviewer of bug 1452699 for details:
Christoph and Valentin, can you please tell us something about that pref. It's causing some cookie problems in our CalDav implementation when talking to certain servers (at least that's what I understand).
Flags: needinfo?(valentin.gosu)
Flags: needinfo?(honzab.moz)
Flags: needinfo?(ckerschb)

Updated

5 months ago
Summary: caldav/carddav does not synchronize with nextcloud in Thunderbird 60 Beta 5 and up → caldav/carddav does not synchronize with nextcloud in Thunderbird 60 Beta 5 and up, workaround: set pref network.cookie.same-site.enabled to false
Comment hidden (obsolete)
Comment hidden (obsolete)
Blocks: 1452699
(In reply to Christian Rütgers from comment #32)
> @Philipp Kewisch
> Issue is not only related to CalDav but also to CardDav as mentioned in the
> subject of this issue.
Cardbook is an add-on, therefore you will have to report the issue to the Cardbook author who will fix it separately from this bug. I'm modifying this bug to only handle the caldav part in Lightning.
User Story: (updated)
Summary: caldav/carddav does not synchronize with nextcloud in Thunderbird 60 Beta 5 and up, workaround: set pref network.cookie.same-site.enabled to false → caldav does not synchronize with nextcloud in Thunderbird 60 Beta 5 and up
User Story: (updated)
Flags: needinfo?(valentin.gosu)

Comment 50

5 months ago
I confirm that Cardbook works with TB60B10 with pref network.cookie.same-site.enabled set to false
(In reply to Jorg K (GMT+2) from comment #46)
> You'd have to ask the author/reviewer of bug 1452699 for details:
> Christoph and Valentin, can you please tell us something about that pref.
> It's causing some cookie problems in our CalDav implementation when talking
> to certain servers (at least that's what I understand).

What do you want to know in particular? We wrote a blogpost (including various links) which might be helpful to get started:
https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60/
Flags: needinfo?(ckerschb)

Comment 52

5 months ago
Any update on this issue? Do you want to solve it before TB60 release?

Comment 53

5 months ago
Isn't the solution to set the preference like we already mention in the release notes:
https://www-stage.thunderbird.net/en-US/thunderbird/60.0beta/releasenotes/

We could switch it off by default. MMD, do you have an opinion? Can you explain the issue to me please. What's special about the NextCloud cookie handling and why does it run into "same site" issues in the first place?
Flags: needinfo?(makemyday)

Comment 54

5 months ago
Since this is a security feature, we should not disable it by default even though the attack vector for caldav/carddav use is limited, but people may use other addons to browse with TB.

If TB/ the network code worked here flawlessly, this can only be an issue of the server to not hanlde it correctly, so we should relnote about the known issue for Nexcloud in the versions mentioned in this bug and advise the user to (only) flip the pref if he/she is seeing the issue.

There is no report yet for any other caldav/dcarddav server and we have reports for some products that it works. However, this doesn't mean there would be no issue with the network code, since these products probably don't use the samesite feature, but since samesite is available in FF since version 60 there should have been bug reports already if something doesn't work (and I used FF to check with demo.nextcloud.com and got no warnings/problems when doing so).
Flags: needinfo?(makemyday)

Comment 55

5 months ago
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #51)
> What do you want to know in particular? We wrote a blogpost (including
> various links) which might be helpful to get started:
> https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60/

Christoph, thank you for pointing to the blog post and offering your assistance. In the findings wrapped up in comment 42, the requests were fired against the same ip address, so no domain name involved. Can you check the server response there and the TB response wether these are appropriate with respect to the rfc so we can exclude at least one side to be responsible for the behaviour - from what I read there, I'm not sure whether it's ok to send strict and lax at the same time?

On the other hand, that should have been an issue for FF as well. Is there a special hanlding for exotic http/dav methods like PROPFIND, OPTIONS or REPORT?

Another thought: since we send our request from javascript (both Lightning and cardbook are technically addons, even Lightning is shipped bundled with TB), could that prevent the cookies from being set by the network code correctly?
Flags: needinfo?(ckerschb)
(In reply to [:MakeMyDay] from comment #55)
> (In reply to Christoph Kerschbaumer [:ckerschb] from comment #51)
> > What do you want to know in particular? We wrote a blogpost (including
> > various links) which might be helpful to get started:
> > https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60/
> 
> Christoph, thank you for pointing to the blog post and offering your
> assistance. In the findings wrapped up in comment 42, the requests were
> fired against the same ip address, so no domain name involved. Can you check
> the server response there and the TB response wether these are appropriate
> with respect to the rfc so we can exclude at least one side to be
> responsible for the behaviour - from what I read there, I'm not sure whether
> it's ok to send strict and lax at the same time?
> 
> On the other hand, that should have been an issue for FF as well. Is there a
> special hanlding for exotic http/dav methods like PROPFIND, OPTIONS or
> REPORT?
> 
> Another thought: since we send our request from javascript (both Lightning
> and cardbook are technically addons, even Lightning is shipped bundled with
> TB), could that prevent the cookies from being set by the network code
> correctly?

Mark, is the author of the spec; 302 to him on your questions above.
Flags: needinfo?(ckerschb) → needinfo?(mgoodwin)

Updated

5 months ago
Duplicate of this bug: 1470679

Comment 58

5 months ago
Mark, any chance that you can comment? We're about to release TB 60 and would like to take this to the release notes.

Comment 59

4 months ago
Maaaaaaaaaaark, we neeeeeeeed youuuuuuuuuuuu :)

Comment 60

4 months ago
Hum, TB60 has been released and this is the single "Known Issues" in the release notes https://www.thunderbird.net/en-US/thunderbird/60.0/releasenotes/

What a pity :( Any chance to fix that soon?

Comment 61

4 months ago
At this point, it's not clear whether there is something to fix at our end at all. And until this changes, relnoting the issue with a workaround recommendation for affected users is an absolutely valid approach to deal with the situation.

And if you're looking over to the NC issue, with not much of activity visible to analyse the issue on the NC side, the answer to your question is probably no. But let's see how things are going with TB60 being releaseed now.

Comment 62

4 months ago
You're right @MakeMyDay and I understand your strategy to release TB. I'm just saying it's a pity that we could not solve this issue, while it has been reported 2 months ago. If it had been solved, you could have released a "clean" TB ;)

I hope NC developers will have a look soon (I messaged them again this morning). On your side, are we still waiting for a comment from Mark (mgoodwin@mozilla.com)?
(In reply to [:MakeMyDay] from comment #58)
> Mark, any chance that you can comment? We're about to release TB 60 and
> would like to take this to the release notes.

Apologies for the delay, I've been off work for a while following an accident.

From the logs, it looks like TB *should* be sending those cookies. I'll get TB60 running so I can try to track down what's up.

(leaving the ni? so I don't forget to follow up)

Comment 64

4 months ago
Hey,

we also encountered this Problem after upgrading TB to 60.0 but only on Windows Maschines.
we have a nextcloud instance hosting calendars for a department.
2 new members got TB 60 fresh installed and i was wondering why the calenders didnt work anymore.
on my maschine however (archlinux) with TB 60 calendar and task are working fine.
the only other difference is that my TB is english and the windows ones are in german.

hope that helps.
(In reply to Martin Fink from comment #64)

Have you tried the "set pref network.cookie.same-site.enabled to false" workaround as noted on top of this bug report and on https://www.thunderbird.net/en-US/thunderbird/60.0/releasenotes/#known-issues ?

Comment 66

4 months ago
(In reply to Stefan Sitter [:ssitter] from comment #65)
> (In reply to Martin Fink from comment #64)
> 
> Have you tried the "set pref network.cookie.same-site.enabled to false"
> workaround as noted on top of this bug report and on
> https://www.thunderbird.net/en-US/thunderbird/60.0/releasenotes/#known-
> issues ?

Hey, yes the workaround worked fine.

Comment 67

4 months ago
Hello Mark, happy to see you back. Did you make any progress? Are you in contact with the Nextcloud team here https://github.com/nextcloud/server/issues/10134 ?
Summary: caldav does not synchronize with nextcloud in Thunderbird 60 Beta 5 and up → CalDAV does not synchronize with Nextcloud if network.cookie.same-site.enabled is true
Duplicate of this bug: 1489148

Comment 69

2 months ago
I can confirm this with Thunderbird 60.2.1 and Lightning 6.2.2.1 connecting to Nextcloud 14.0.3 (over apache 2.4.18 and https).

I had the error "[calCachedCalendar] replay action failed: null, uri=https://foo.bar/, result=2147500037, operation=[xpconnect wrapped calIOperation]" when starting thunderbird from terminal.
Disabling offline support made this error go away, but did not help otherwise.

The workaround to set network.cookie.same-site.enabled to false helped.

Updated

a month ago
Duplicate of this bug: 1499665

Updated

a month ago
Duplicate of this bug: 1504598
Hi!
I am not 100% sure if my problem is related to this reported bug. But I cannot synchronize my nextcloud (14.0.4) calendar with Thunderbird 60.3.2 (32-Bit) / Lightning 6.2.3.3. Neither with enabled or disabled network.cookie.same-site. With a web browser I can connect to the nc WebDAV page, getting the message that this is for WebDAV clients only. So I suppose in principle it should be possible to connect to the calendar. 
As the nc installation is on a hosted / shared webspace (in some subfolder) I do not have too many debug options. But as far as I could see there are no errors reported in the logs provided. In TB it only states that the calendar is temporarily unavailable. Is there any option to investigate this further? 

Christian

Comment 73

4 days ago
@christian.kohler(In reply to christian.kohler from comment #72)
> cannot synchronize my nextcloud (14.0.4) calendar with Thunderbird 60.3.2
> (32-Bit) / Lightning 6.2.3.3. Neither with enabled or disabled
> network.cookie.same-site.

CardDAV and CalDAV work fine for me with network.cookie.same-site.enabled = false in NC 14.0.4 with TB 60.3.2 (32-bit) and integrated Lightning 6.2.3.2 (not 6.2.3.3).


I used the following URL: https://example.org/remote.php/dav/calendars/MYUSERNAME/personal/

You could try connecting with another client to see whether CalDAV works at all. DAVdroid for Android has been a reliable client (free on f-droid, donations are encouraged).
(In reply to gol3m from comment #73)
> @christian.kohler(In reply to christian.kohler from comment #72)
> > cannot synchronize my nextcloud (14.0.4) calendar with Thunderbird 60.3.2
> > (32-Bit) / Lightning 6.2.3.3. Neither with enabled or disabled
> > network.cookie.same-site.
> 
> CardDAV and CalDAV work fine for me with network.cookie.same-site.enabled =
> false in NC 14.0.4 with TB 60.3.2 (32-bit) and integrated Lightning 6.2.3.2
> (not 6.2.3.3).
> 
> 
> I used the following URL:
> https://example.org/remote.php/dav/calendars/MYUSERNAME/personal/
> 
> You could try connecting with another client to see whether CalDAV works at
> all. DAVdroid for Android has been a reliable client (free on f-droid,
> donations are encouraged).

Hi!
Thanks for the reply, I made a donation ;-) DAVDroid works like charm and I found some information in DAVdroid, that helped me getting things working with TB/L as well. I share this here in case someone else has the same problem.
Nextcloud pointed me to a url of the type https://mydomainname/firstsubfolder/secondsubfolder/remote.php/dav/ which worked fine in DAVdroid but caused the problem described in TB. But in the DAVdroid properties of the calendar I found a little extended version of this url: https://mydomainname/firstsubfolder/secondsubfolder/remote.php/dav/calendars/myname/personal. Using this url in TB and everything works, even with network.cookie.same-site.enabled = true
Cheers
Chris
You need to log in before you can comment on or make changes to this bug.