Closed
Bug 853236
Opened 11 years ago
Closed 11 years ago
Provide access to Google CalDAV v2 API
Categories
(Calendar :: Provider: CalDAV, defect)
Calendar
Provider: CalDAV
Tracking
(Not tracked)
RESOLVED
FIXED
2.6
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 ***
Assignee | ||
Comment 1•11 years ago
|
||
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.
Comment 2•11 years ago
|
||
Comment on attachment 727694 [details] [diff]
Fix - v1
Looks like the patch is missing a file.
Assignee | ||
Comment 3•11 years ago
|
||
Ah yes, here is the patch with file
Comment 4•11 years ago
|
||
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?
Assignee | ||
Comment 5•11 years ago
|
||
https://apidata.googleusercontent.com/caldav/v2/[calid]/events
Assignee | ||
Comment 8•11 years ago
|
||
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.
Assignee | ||
Comment 9•11 years ago
|
||
Pushed to comm-central changeset 723ed450d2e7
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•11 years ago
|
Target Milestone: --- → 2.6
Comment 10•11 years ago
|
||
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.
Assignee | ||
Comment 11•11 years ago
|
||
Mmh that doesn't sound too good. These master passwords are really a pain! Any idea why its happening?
Assignee | ||
Comment 12•11 years ago
|
||
The moz.build info was missing, probably due to bitrot. Bustage fix here: https://hg.mozilla.org/comm-central/rev/6f04beca8b73 https://hg.mozilla.org/releases/comm-aurora/rev/d5da57105c97
Comment 13•11 years ago
|
||
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?
Assignee | ||
Comment 14•11 years ago
|
||
Go ahead and file public bugs, just keeping this one private because it contains the key in plaintext.
Updated•8 years ago
|
Group: core-security → core-security-release
Updated•8 years ago
|
Whiteboard: private for non-security reasons. → private because keys in plaintext
Updated•8 years ago
|
Flags: needinfo?(philipp)
Updated•8 years ago
|
Group: mail-core-security
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(philipp)
Updated•8 years ago
|
Keywords: sec-other
Whiteboard: private because keys in plaintext → hidden patches/comments due to keys in plaintext
Updated•8 years ago
|
Group: mail-core-security, core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•