<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 4/29/14, 7:01 PM, <a class="moz-txt-link-abbreviated" href="mailto:neandr@gmx.de">neandr@gmx.de</a>
wrote:<br>
</div>
<blockquote cite="mid:535FDAF8.6080701@gmx.de" type="cite">On
29.04.2014 18:17, Ben Bucksch wrote:
<br>
<blockquote type="cite"><a class="moz-txt-link-abbreviated" href="mailto:neandr@gmx.de">neandr@gmx.de</a> wrote, On 28.04.2014 20:10:
<br>
<blockquote type="cite">Lightning hides that process from the
user.
<br>
That access key will be used to generate a token to work with
your mail/calendar. That token will expire after a certain
time and your application (mail/calendar) needs to generate a
new token. Normally the user should not notice about that for
any session. </blockquote>
<br>
Expiry indeed is a core problem. One-time setup - if it's really
once and then never again - can be handled differently than
something that can up at any random time.
<br>
<br>
How does that process work? All readable documentation I found
about OAuth speaks about webpages. That is: not HTTP URLs, but
random HTML served by Google, containing arbitrary challenges to
the end user (e.g. enter phone number, Google sending a code
there, enter that code) that only the allowed human can fulfill.
<br>
<br>
If tokens can expire and be refreshed by Lightning without (!)
user interaction, I don't know how that would work. Can you
expand, please?
<br>
<br>
</blockquote>
[...]<br>
<br>
Lightning does that first process to get the very first access and
refresh code a bit more elegant. I think Philipp (Fallen) could
give a more detailed description here.
<br>
<br>
</blockquote>
<br>
I think some things have changed, reading the docs there is now also
an token info service that must be called. We don't do this. Anyway,
most of the process we do can be found in
<a class="moz-txt-link-rfc2396E" href="http://mxr.mozilla.org/comm-central/source/calendar/base/modules/OAuth2.jsm"><http://mxr.mozilla.org/comm-central/source/calendar/base/modules/OAuth2.jsm></a>.
First we get an authorization token, then we can request an access
token. The access token expires in given time (as stated in the
response). When the access token has expired, we can refresh it
using the authorization token without any user interaction. The user
must only enter data when getting the authorization token.<br>
<br>
More information on the general process is here:
<a class="moz-txt-link-rfc2396E" href="https://developers.google.com/accounts/docs/OAuth2"><https://developers.google.com/accounts/docs/OAuth2></a>. Here is
info specifically on how it works for client applications
<a class="moz-txt-link-rfc2396E" href="https://developers.google.com/accounts/docs/OAuth2UserAgent"><https://developers.google.com/accounts/docs/OAuth2UserAgent></a>.
Note that some data needs to be pushed to the source repository.
Please make sure it is properly obfuscated, as seen here
<a class="moz-txt-link-rfc2396E" href="http://mxr.mozilla.org/comm-central/source/calendar/providers/caldav/calDavCalendar.js#2855"><http://mxr.mozilla.org/comm-central/source/calendar/providers/caldav/calDavCalendar.js#2855></a>
and add a similar comment.<br>
<br>
Philipp<br>
<div style="bottom: auto; left: 928px; right: auto; top: 515px;
display: none;" class="translator-theme-default"
id="translator-floating-panel">
<div title="Click to translate"
id="translator-floating-panel-button"></div>
</div>
</body>
</html>