Closed Bug 853236 Opened 8 years ago Closed 8 years ago

Provide access to Google CalDAV v2 API

Categories

(Calendar :: Provider: CalDAV, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Fallen, Assigned: Fallen)

References

Details

(Whiteboard: hidden patches/comments due to keys in plaintext)

Google is shutting down their v1 API, we need to move to the new one that uses OAuth. This means we need to provide OAuth authentication for the caldav provider, likely special cased on the hostname.

I've tested this already with a static auth key and the caldav endpoint works fine. I just need to flash the OAuth window. Thunderbird has some OAuth code already, but last I tried this needs some modifications to work with Google's OAuth implementation.

I had hoped I can use nsIHttpAuthenticator, but its synchronous and Google doesn't provide the right values on a 401.

*** This is confidential, please leave this bug secure ***
Attached patch Fix - v1 (obsolete) β€” β€” Splinter Review
This should take care. I don't know if all Google accounts secretly have this enabled yet, but if you can I'd appreciate some testing.
Keywords: sec-other
Whiteboard: private for non-security reasons.
Comment on attachment 727694 [details] [diff]
Fix - v1

Looks like the patch is missing a file.
Attached patch Fix - v2 β€” β€” Splinter Review
Ah yes, here is the patch with file
It looks like the host name that triggers the use of OAuth is "apidata.googleusercontent.com". What URL do you need to use for the calendar location to use v2 of the API?
For this to be public, I'm going to have to apply some obfuscation to the part of the code that holds the OAuth secrets. I've discussed this with the Google folks and we have come to a solution that works for both of us. Patch coming soon.
Pushed to comm-central changeset 723ed450d2e7
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.6
From a quick test this seems to work but I noticed a problem after setting up a master password in Thunderbird. Thunderbird will not startup anymore, the master password prompt will appear partially but is not operable and Thunderbird uses 100 % CPU cycles. Thunderbird starts fine again if I switch off the calendar by setting "calendar.registry.<id>.disabled" to true for the calendar.
Mmh that doesn't sound too good. These master passwords are really a pain! Any idea why its happening?
Do you consider this feature public now, i.e. we can go ahead and file public bugs for missing features or enhancement requests or problems like mentioned in comment 10? Or should they be filed as security hidden?
Go ahead and file public bugs, just keeping this one private because it contains the key in plaintext.
Group: core-security → core-security-release
Whiteboard: private for non-security reasons. → private because keys in plaintext
Flags: needinfo?(philipp)
Group: mail-core-security
Flags: needinfo?(philipp)
Keywords: sec-other
Whiteboard: private because keys in plaintext → hidden patches/comments due to keys in plaintext
Group: mail-core-security, core-security-release
You need to log in before you can comment on or make changes to this bug.