Closed Bug 853236 Opened 11 years ago Closed 11 years ago
Provide access to Google Cal
DAV v2 API
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 ***
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.
Whiteboard: private for non-security reasons.
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: 11 years ago
Resolution: --- → FIXED
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?
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
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.
Whiteboard: private for non-security reasons. → private because keys in plaintext
Whiteboard: private because keys in plaintext → hidden patches/comments due to keys in plaintext
You need to log in before you can comment on or make changes to this bug.