OAuth2 implementation in Elisp

OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

Hi there,

I wrote a small implementation of the OAuth 2.0 Authorization Protocol¹
client in Elisp, using `url' to make the HTTP requests and `plstore' to
store the tokens permanently.

Is there any interest in merging this into the trunk or should I keep it
outside?

¹  http://tools.ietf.org/html/draft-ietf-oauth-v2-22

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Deniz Dogan]

On 2011-09-22 23:55, Julien Danjou wrote:
> Hi there,
>
> I wrote a small implementation of the OAuth 2.0 Authorization Protocol¹
> client in Elisp, using `url' to make the HTTP requests and `plstore' to
> store the tokens permanently.
>
> Is there any interest in merging this into the trunk or should I keep it
> outside?
>
> ¹  http://tools.ietf.org/html/draft-ietf-oauth-v2-22
>

Ooh, nice!  I am personally happy to see that someone finally 
implemented this, although I haven't had the time to test it yet.  I'm 
not sure its relatively few use cases justify including it in Emacs 
trunk though.

Re: OAuth2 implementation in Elisp

[Deniz Dogan]

On 2011-09-22 23:59, Deniz Dogan wrote:
> On 2011-09-22 23:55, Julien Danjou wrote:
>> Hi there,
>>
>> I wrote a small implementation of the OAuth 2.0 Authorization Protocol¹
>> client in Elisp, using `url' to make the HTTP requests and `plstore' to
>> store the tokens permanently.
>>
>> Is there any interest in merging this into the trunk or should I keep it
>> outside?
>>
>> ¹ http://tools.ietf.org/html/draft-ietf-oauth-v2-22
>>
>
> Ooh, nice! I am personally happy to see that someone finally implemented
> this, although I haven't had the time to test it yet. I'm not sure its
> relatively few use cases justify including it in Emacs trunk though.
>

Uh, where is the code by the way?

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1.1: Type: text/plain, Size: 377 bytes --]

On Fri, Sep 23 2011, Deniz Dogan wrote:

> Uh, where is the code by the way?

Well, I did not published it yet, since I don't want to set up a Git
repository if it's OK to merge this into the trunk. And I usually don't
like sending code by e-mail, since there's always a chance someone will
grab old code from this to-be-outdated mail in the future.

But well, here it is. :)


[-- Attachment #1.2: oauth2.el --]
[-- Type: application/emacs-lisp, Size: 7566 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 22 bytes --]


-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Stefan Monnier]

> I wrote a small implementation of the OAuth 2.0 Authorization Protocol¹
> client in Elisp, using `url' to make the HTTP requests and `plstore' to
> store the tokens permanently.

> Is there any interest in merging this into the trunk or should I keep it
> outside?

In trunk?  No, at least not now.  But in GNU ELPA, very much so, yes.


        Stefan

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

On Fri, Sep 23 2011, Stefan Monnier wrote:

> In trunk?  No, at least not now.  But in GNU ELPA, very much so, yes.

I understand the "no" part, but not "not now". Why not now?

Anyway I got my answer, so I'll go publish the thing myself as I usually
do. Thanks. :)

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Andreas Röhler]

Am 23.09.2011 09:31, schrieb Julien Danjou:
> On Fri, Sep 23 2011, Stefan Monnier wrote:
>
>> In trunk?  No, at least not now.  But in GNU ELPA, very much so, yes.
>
> I understand the "no" part, but not "not now". Why not now?
>
> Anyway I got my answer, so I'll go publish the thing myself as I usually
> do. Thanks. :)
>

Hi Julien,

IIUC having the code in ELPA it's pretty much like in trunk. Should be a 
lot easier for people to know about and install from ELPA than picking 
it from the net.

Think it's worth preparing it.


Cheers,

Andreas

Re: OAuth2 implementation in Elisp

[Michael Albinus]

Julien Danjou <julien@danjou.info> writes:

> On Fri, Sep 23 2011, Stefan Monnier wrote:
>
>> In trunk?  No, at least not now.  But in GNU ELPA, very much so, yes.
>
> I understand the "no" part, but not "not now". Why not now?

Feature freeze. Starting pretest.

> Anyway I got my answer, so I'll go publish the thing myself as I usually
> do. Thanks. :)

I second Andreas, please bring it to GNU ELPA.

Best regards, Michael.

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On Fri, Sep 23 2011, Michael Albinus wrote:

> Feature freeze. Starting pretest.

Oh ok. Did not think about that, since it's impacting Emacs directly.

>> Anyway I got my answer, so I'll go publish the thing myself as I usually
>> do. Thanks. :)
>
> I second Andreas, please bring it to GNU ELPA.

Is there any documentation about adding packages to GNU ELPA, using it,
etc?

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Michael Albinus]

Julien Danjou <julien@danjou.info> writes:

> Is there any documentation about adding packages to GNU ELPA, using it,
> etc?

admin/notes/elpa

Best regards, Michael.

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Fri, 23 Sep 2011 00:15:19 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Fri, Sep 23 2011, Deniz Dogan wrote:
>> Uh, where is the code by the way?

JD> Well, I did not published it yet, since I don't want to set up a Git
JD> repository if it's OK to merge this into the trunk. And I usually don't
JD> like sending code by e-mail, since there's always a chance someone will
JD> grab old code from this to-be-outdated mail in the future.

JD> But well, here it is. :)

Could you format it to wrap the long lines?

Some usage examples would be nice.

I don't think you are encoding URL parameters so your URLs are not
safely constructed.  I think the url libraries have functions for that;
you could also submit a POST (if OAuth2 supports it, I don't know the
spec) so you don't have to encode things at all.

Can `oauth2-request-authorization' be automated so the user doesn't have
to enter a string they see on the screen?  That seems painful.

Thanks
Ted

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

On Sun, Sep 25 2011, Ted Zlatanov wrote:

> Could you format it to wrap the long lines?

Long? What's the limit? The longest is 122, which does not seem long to
me in 2011.

> Some usage examples would be nice.

Sure, I'll may be add, but the commentary should be enough for anybody
to start using it. :)

> I don't think you are encoding URL parameters so your URLs are not
> safely constructed.  I think the url libraries have functions for that;
> you could also submit a POST (if OAuth2 supports it, I don't know the
> spec) so you don't have to encode things at all.

It is a POST request for the authorization request. And about encoding,
I'm not sure there's actually a problem, but if you could point me on a
specific point I'd be glad to take a look.

> Can `oauth2-request-authorization' be automated so the user doesn't have
> to enter a string they see on the screen?  That seems painful.

If Emacs was a Web app, yes.

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Sun, 25 Sep 2011 14:56:20 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Sun, Sep 25 2011, Ted Zlatanov wrote:
>> Could you format it to wrap the long lines?

JD> Long? What's the limit? The longest is 122, which does not seem long to
JD> me in 2011.

If you could stay under 78 it would be polite.  I can't find the
reference but I'm pretty sure for Emacs submissions at least it's
required.

>> Some usage examples would be nice.

JD> Sure, I'll may be add, but the commentary should be enough for anybody
JD> to start using it. :)

It wasn't for me, sorry.  I don't know OAuth2 well.

>> I don't think you are encoding URL parameters so your URLs are not
>> safely constructed.  I think the url libraries have functions for that;
>> you could also submit a POST (if OAuth2 supports it, I don't know the
>> spec) so you don't have to encode things at all.

JD> It is a POST request for the authorization request. And about encoding,
JD> I'm not sure there's actually a problem, but if you could point me on a
JD> specific point I'd be glad to take a look.

#+begin_src lisp
  (browse-url (concat auth-url
                      (if (string-match-p "\?" auth-url) "&" "?")
                      "client_id=" client-id
                      "&response_type=code&redirect_uri=urn:ietf:wg:oauth:2.0:oob"
                      (if scope (concat "&scope=" (url-hexify-string scope)) "")
                      (if state (concat "&state=" state) "")))

#+end_src

This is not a POST and `client_id' for instance could have invalid
characters for a URL.

>> Can `oauth2-request-authorization' be automated so the user doesn't have
>> to enter a string they see on the screen?  That seems painful.

JD> If Emacs was a Web app, yes.

That makes no sense.  You are asking the user to enter information Emacs
is displaying.  Can you grab that information for them, so they don't
have to enter it?

Thanks
Ted

Re: OAuth2 implementation in Elisp

[Karl Fogel]

Ted Zlatanov <tzz@lifelogs.com> writes:
>On Sun, 25 Sep 2011 14:56:20 +0200 Julien Danjou <julien@danjou.info> wrote: 
>JD> On Sun, Sep 25 2011, Ted Zlatanov wrote:
>>> Could you format it to wrap the long lines?
>
>JD> Long? What's the limit? The longest is 122, which does not seem long to
>JD> me in 2011.
>
>If you could stay under 78 it would be polite.  I can't find the
>reference but I'm pretty sure for Emacs submissions at least it's
>required.

Yes, 78 has been the standard for a long time AFAICT, with 80 as the
hard limit only when absolutely necessary.  search://80 column rule/
will bring up lots of links about it.  This is one of the best:

  http://www.emacswiki.org/emacs/EightyColumnRule

As that resource (and others) note, it's not merely historical baggage
left over from old fixed-width terminals -- it's rather an accessibility
issue and human optimum-scanning-width issue.

HTH,
-Karl

Re: OAuth2 implementation in Elisp

[Deniz Dogan]

On 2011-09-25 14:56, Julien Danjou wrote:
> On Sun, Sep 25 2011, Ted Zlatanov wrote:
>
>> Could you format it to wrap the long lines?
>
> Long? What's the limit? The longest is 122, which does not seem long to
> me in 2011.
>

Maybe not in languages such as C#... ;)

Honestly, that line didn't fit on one visual line on my monitor, which 
is a 22 inch widescreen, because I normally keep two windows 
side-by-side open.  122 characters is way too long, especially when it's 
so easy to "fix" that in this case.

Re: OAuth2 implementation in Elisp

[Justin Lilly]

w/r/t the entering a string, this is part of how oauth2 works for
desktop applications. The other workflow is for web apps specifically.
Familiarizing yourself with the spec might make reviewing the code a
bit more sane as it should clear up some of these ambiguities.

 -justin

2011/9/25 Ted Zlatanov <tzz@lifelogs.com>:
> On Sun, 25 Sep 2011 14:56:20 +0200 Julien Danjou <julien@danjou.info> wrote:
>
> JD> On Sun, Sep 25 2011, Ted Zlatanov wrote:
>>> Could you format it to wrap the long lines?
>
> JD> Long? What's the limit? The longest is 122, which does not seem long to
> JD> me in 2011.
>
> If you could stay under 78 it would be polite.  I can't find the
> reference but I'm pretty sure for Emacs submissions at least it's
> required.
>
>>> Some usage examples would be nice.
>
> JD> Sure, I'll may be add, but the commentary should be enough for anybody
> JD> to start using it. :)
>
> It wasn't for me, sorry.  I don't know OAuth2 well.
>
>>> I don't think you are encoding URL parameters so your URLs are not
>>> safely constructed.  I think the url libraries have functions for that;
>>> you could also submit a POST (if OAuth2 supports it, I don't know the
>>> spec) so you don't have to encode things at all.
>
> JD> It is a POST request for the authorization request. And about encoding,
> JD> I'm not sure there's actually a problem, but if you could point me on a
> JD> specific point I'd be glad to take a look.
>
> #+begin_src lisp
>  (browse-url (concat auth-url
>                      (if (string-match-p "\?" auth-url) "&" "?")
>                      "client_id=" client-id
>                      "&response_type=code&redirect_uri=urn:ietf:wg:oauth:2.0:oob"
>                      (if scope (concat "&scope=" (url-hexify-string scope)) "")
>                      (if state (concat "&state=" state) "")))
>
> #+end_src
>
> This is not a POST and `client_id' for instance could have invalid
> characters for a URL.
>
>>> Can `oauth2-request-authorization' be automated so the user doesn't have
>>> to enter a string they see on the screen?  That seems painful.
>
> JD> If Emacs was a Web app, yes.
>
> That makes no sense.  You are asking the user to enter information Emacs
> is displaying.  Can you grab that information for them, so they don't
> have to enter it?
>
> Thanks
> Ted
>
>
>

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

On Sun, Sep 25 2011, Ted Zlatanov wrote:

> If you could stay under 78 it would be polite.  I can't find the
> reference but I'm pretty sure for Emacs submissions at least it's
> required.

Fine.

> #+begin_src lisp
>   (browse-url (concat auth-url
>                       (if (string-match-p "\?" auth-url) "&" "?")
>                       "client_id=" client-id
>                       "&response_type=code&redirect_uri=urn:ietf:wg:oauth:2.0:oob"
>                       (if scope (concat "&scope=" (url-hexify-string scope)) "")
>                       (if state (concat "&state=" state) "")))
>
> #+end_src
>
> This is not a POST and `client_id' for instance could have invalid
> characters for a URL.

Good catch indeed. I'll do a re-check of such things then and will fix
them before they break. :-)

> That makes no sense.  You are asking the user to enter information Emacs
> is displaying.  Can you grab that information for them, so they don't
> have to enter it?

No, this would kill the whole point of OAuth. You may want to take a
look at the spec of the protocol to understand how it works. :)

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Mon, 26 Sep 2011 11:52:54 +0200 Julien Danjou <julien@danjou.info> wrote: 

>> That makes no sense.  You are asking the user to enter information Emacs
>> is displaying.  Can you grab that information for them, so they don't
>> have to enter it?

JD> No, this would kill the whole point of OAuth. You may want to take a
JD> look at the spec of the protocol to understand how it works. :)

On Sun, 25 Sep 2011 13:50:05 -0700 Justin Lilly <justin@justinlilly.com> wrote: 

JL> w/r/t the entering a string, this is part of how oauth2 works for
JL> desktop applications. The other workflow is for web apps specifically.
JL> Familiarizing yourself with the spec might make reviewing the code a
JL> bit more sane as it should clear up some of these ambiguities.

Why can't Emacs behave like a web app?

I used OAuth 1 which had a similarly annoying feature.  It made it very
unlikely for users to try my code and I got many bug reports.  So I hope
we can avoid it.

The OAuth 2 spec (I found it at http://tools.ietf.org/html/draft-ietf-oauth-v2-22)
seems to provide for a seamless experience where the user authenticates
against a server and then the security code is fed back to the client
application through a redirect.  Perhaps I'm misunderstanding the flow;
my question is simply "if there's information Emacs knows, can you
please avoid asking the user to retype it?"  

I hope I don't have to know how to implement OAuth2 in order to
understand your answer to that question.

Ted

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Mon, Sep 26 2011, Ted Zlatanov wrote:

> I hope I don't have to know how to implement OAuth2 in order to
> understand your answer to that question.

No. But you have to understand how it works and how to use it at least,
so your questions would make sense. Right now you are just proving you
know nothing about OAuth 2 and that you don't trust my judgement on
implementing things.
Which could put me in a bad mood.

Now, I'll explain why we can't make Emacs act like a Web apps to you.

When the client is a native client (like Emacs), the user is sent to an
URL where the OAuth provider prints the following:

"The application $REGISTERED-APPLICATION-NAME is trying to access your
 data in $THIS-WAY. Is this OK?

  [YES] [NO]"

If the user clicks yes, an authorization code is printed, the user give
it to Emacs, and Emacs can obtain an access token from the OAuth
provider to access the user data. Point.

If the client is a Web application, the user is sent to the same URL,
but when clicking [YES], no code are printed: instead the user is
redirected by to the Web application.


Therefore, I don't think there is any reasonable way to make Emacs parse
the authorization page and click YES itself instead of the user, or to
make Emacs a Web application that we can redirect the user to.

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> When the client is a native client (like Emacs), the user is sent to an
> URL where the OAuth provider prints the following:
>
> "The application $REGISTERED-APPLICATION-NAME is trying to access your
>  data in $THIS-WAY. Is this OK?
>
>   [YES] [NO]"

What you mean by "sent to an URL"?  Do you mean that Emacs fetches the
URL and displays the "[YES] [NO]"?  And if not -- why not?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

On Mon, Sep 26 2011, Lars Magne Ingebrigtsen wrote:

> What you mean by "sent to an URL"?  Do you mean that Emacs fetches the
> URL and displays the "[YES] [NO]"?  And if not -- why not?

No no, it does not fetch anything, it calls browse-url.

The format of the page is not standard, so there's no way you can
display it in Emacs. Really.

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> The format of the page is not standard, so there's no way you can
> display it in Emacs. Really.

Why not?  

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Mon, 26 Sep 2011 17:04:18 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Mon, Sep 26 2011, Ted Zlatanov wrote:
>> I hope I don't have to know how to implement OAuth2 in order to
>> understand your answer to that question.

JD> No. But you have to understand how it works and how to use it at least,
JD> so your questions would make sense. Right now you are just proving you
JD> know nothing about OAuth 2 and that you don't trust my judgement on
JD> implementing things.

That's a stretch based on my questions, especially the latter part.

JD> Which could put me in a bad mood.

Sorry to hear that.  I am interested in a) using this code myself, and
b) making sure users don't send me questions like "what do I do now?
Emacs is asking me to enter some code."  From my viewpoint what you
posted will not help with (b).  Upsetting you was not intended.

JD> Now, I'll explain why we can't make Emacs act like a Web apps to you.

JD> When the client is a native client (like Emacs), the user is sent to an
JD> URL where the OAuth provider prints the following:

JD> "The application $REGISTERED-APPLICATION-NAME is trying to access your
JD>  data in $THIS-WAY. Is this OK?

JD>   [YES] [NO]"

JD> If the user clicks yes, an authorization code is printed, the user give
JD> it to Emacs, and Emacs can obtain an access token from the OAuth
JD> provider to access the user data. Point.

JD> If the client is a Web application, the user is sent to the same URL,
JD> but when clicking [YES], no code are printed: instead the user is
JD> redirected by to the Web application.

This is what I saw in the IETF draft.  It is the better workflow.
Asking users to retype visible strings in Emacs is... unusual for an API.

Why can't Emacs pretend to be a Web application?  Is it somehow less
capable than other web browsers?

Thanks
Ted

Re: OAuth2 implementation in Elisp

[joakim]

Julien Danjou <julien@danjou.info> writes:

> On Mon, Sep 26 2011, Lars Magne Ingebrigtsen wrote:
>
>> What you mean by "sent to an URL"?  Do you mean that Emacs fetches the
>> URL and displays the "[YES] [NO]"?  And if not -- why not?
>
> No no, it does not fetch anything, it calls browse-url.
>
> The format of the page is not standard, so there's no way you can
> display it in Emacs. Really.

I know nothing about this but out of curiousity: could it in principle
be done using the emacs xwidget webkit branch? There is some support to
access the DOM etc. there.

-- 
Joakim Verona

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Mon, 26 Sep 2011 19:47:05 +0200 joakim@verona.se wrote: 

j> Julien Danjou <julien@danjou.info> writes:
>> On Mon, Sep 26 2011, Lars Magne Ingebrigtsen wrote:
>> 
>>> What you mean by "sent to an URL"?  Do you mean that Emacs fetches the
>>> URL and displays the "[YES] [NO]"?  And if not -- why not?
>> 
>> No no, it does not fetch anything, it calls browse-url.
>> 
>> The format of the page is not standard, so there's no way you can
>> display it in Emacs. Really.

j> I know nothing about this but out of curiousity: could it in principle
j> be done using the emacs xwidget webkit branch? There is some support to
j> access the DOM etc. there.

SHR (see gnus/shr.el) could probably do it too, and it's in the trunk
already.  But I'd rather pretend we're a web app and skip even this step
if possible, following the URL redirects instead.  I think that's
possible based on my reading of the IETF OAuth2 draft.

Ted

Re: OAuth2 implementation in Elisp

[Tassilo Horn]

Ted Zlatanov <tzz@lifelogs.com> writes:

>>> The format of the page is not standard, so there's no way you can
>>> display it in Emacs. Really.
>
> j> I know nothing about this but out of curiousity: could it in principle
> j> be done using the emacs xwidget webkit branch? There is some support to
> j> access the DOM etc. there.
>
> SHR (see gnus/shr.el) could probably do it too, and it's in the trunk
> already.  But I'd rather pretend we're a web app and skip even this step
> if possible, following the URL redirects instead.  I think that's
> possible based on my reading of the IETF OAuth2 draft.

I don't know the OAuth spec, but you seem to imply that the pages
showing the yes-no-buttons and the authentication code need to be HTML.
But I understand Julien so that this is really arbitrary: some
JavaScript that has to be interpreted, an image, a video (with 30
seconds beer ad before), or even some flash stuff.

Bye,
Tassilo

Re: OAuth2 implementation in Elisp

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> But I understand Julien so that this is really arbitrary: some
> JavaScript that has to be interpreted, an image, a video (with 30
> seconds beer ad before), or even some flash stuff.

If it's JS or Flash, then Emacs can't do it.  (Yet.  :-)
But is that common?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: OAuth2 implementation in Elisp

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> But I understand Julien so that this is really arbitrary: some
>> JavaScript that has to be interpreted, an image, a video (with 30
>> seconds beer ad before), or even some flash stuff.
>
> If it's JS or Flash, then Emacs can't do it.  (Yet.  :-)
> But is that common?

Not sure.  I've just test-driven Julien's google-contacts.el which uses
oauth2.el, and the google page showing the auth code constists of first
a large part of JavaScript and CSS stuff and then plain but complex HTML
where the auth code is inside a <textarea>...</textarea>.

Possibly, one could rip out the code of the page with some heuristics,
but that doesn't look very promising in the general case...

Bye,
Tassilo

Re: OAuth2 implementation in Elisp

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Not sure.  I've just test-driven Julien's google-contacts.el which uses
> oauth2.el, and the google page showing the auth code constists of first
> a large part of JavaScript and CSS stuff and then plain but complex HTML
> where the auth code is inside a <textarea>...</textarea>.
>
> Possibly, one could rip out the code of the page with some heuristics,
> but that doesn't look very promising in the general case...

But if it's (commonly) just a form, then at least it could all be done
inside Emacs, I think?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Mon, 26 Sep 2011 17:04:18 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> When the client is a native client (like Emacs), the user is sent to an
JD> URL where the OAuth provider prints the following:

JD> "The application $REGISTERED-APPLICATION-NAME is trying to access your
JD>  data in $THIS-WAY. Is this OK?

JD>   [YES] [NO]"

JD> If the user clicks yes, an authorization code is printed, the user give
JD> it to Emacs, and Emacs can obtain an access token from the OAuth
JD> provider to access the user data. Point.

You are asking the user to visit a URL (with `browse-url') with an
external web browser that can run Javascript, then maybe they get back
an auth code, and then they paste it back to Emacs.  The way you have
written oauth2.el, anyone that has customized `browse-url' to use w3m or
other non-Javascript browsers will not know that something went wrong.
Maybe oauth2.el should check for that case.

Ted

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Mon, 26 Sep 2011 22:29:58 +0200 Tassilo Horn <tassilo@member.fsf.org> wrote: 

TH> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>> But I understand Julien so that this is really arbitrary: some
>>> JavaScript that has to be interpreted, an image, a video (with 30
>>> seconds beer ad before), or even some flash stuff.
>> 
>> If it's JS or Flash, then Emacs can't do it.  (Yet.  :-)
>> But is that common?

TH> Not sure.  I've just test-driven Julien's google-contacts.el which uses
TH> oauth2.el, and the google page showing the auth code constists of first
TH> a large part of JavaScript and CSS stuff and then plain but complex HTML
TH> where the auth code is inside a <textarea>...</textarea>.

TH> Possibly, one could rip out the code of the page with some heuristics,
TH> but that doesn't look very promising in the general case...

Experimenting with the Google OAuth2 API (they have docs and examples at
http://code.google.com/apis/accounts/docs/OAuth2.html), I think it may
be possible to extract the bootstrap auth code from the HTML <title>
tag.  The title is filled in before any Javascript is run--it comes back
in the HTTP response.  I don't know if that will work in the general
case, as you say, but at least for that one big provider it would be
possible to parse that part of the interaction.

Ted

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Mon, Sep 26 2011, Lars Magne Ingebrigtsen wrote:

> Julien Danjou <julien@danjou.info> writes:
>
>> The format of the page is not standard, so there's no way you can
>> display it in Emacs. Really.
>
> Why not?  

For example, in the service I use, the page is full of JavaScript and
the action button will not work unless Emacs is now able to render
correctly a Web page with current Web technology like CSS and
JavaScript. Which I think it is unfortunately unable to. :(

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Mon, Sep 26 2011, Tassilo Horn wrote:

> Not sure.  I've just test-driven Julien's google-contacts.el which uses
> oauth2.el, and the google page showing the auth code constists of first
> a large part of JavaScript and CSS stuff and then plain but complex HTML
> where the auth code is inside a <textarea>...</textarea>.

Yeah, but please recall yourself you had to click on a button before
having this code in a textarea.

I really doubt that:
- it's easy to "click" on a JavaScript button from Emacs;
- it's a good idea to answer question instead of the user, this is not
  the point of the spec. The question and the code are not there to piss
  developers off. :-)

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[joakim]

Julien Danjou <julien@danjou.info> writes:

> On Mon, Sep 26 2011, Tassilo Horn wrote:
>
>> Not sure.  I've just test-driven Julien's google-contacts.el which uses
>> oauth2.el, and the google page showing the auth code constists of first
>> a large part of JavaScript and CSS stuff and then plain but complex HTML
>> where the auth code is inside a <textarea>...</textarea>.
>
> Yeah, but please recall yourself you had to click on a button before
> having this code in a textarea.
>
> I really doubt that:
> - it's easy to "click" on a JavaScript button from Emacs;

Just for the record, this is possible in the xwidget branch!


> - it's a good idea to answer question instead of the user, this is not
>   the point of the spec. The question and the code are not there to piss
>   developers off. :-)



-- 
Joakim Verona

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Tue, 27 Sep 2011 11:50:51 +0200 joakim@verona.se wrote: 

j> Julien Danjou <julien@danjou.info> writes:

>> I really doubt that:
>> - it's easy to "click" on a JavaScript button from Emacs;

j> Just for the record, this is possible in the xwidget branch!

Is there a plan to merge that branch with the trunk?

Ted

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Mon, 26 Sep 2011 16:23:48 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Mon, 26 Sep 2011 17:04:18 +0200 Julien Danjou <julien@danjou.info> wrote: 
JD> When the client is a native client (like Emacs), the user is sent to an
JD> URL where the OAuth provider prints the following:

JD> "The application $REGISTERED-APPLICATION-NAME is trying to access your
JD> data in $THIS-WAY. Is this OK?

JD> [YES] [NO]"

JD> If the user clicks yes, an authorization code is printed, the user give
JD> it to Emacs, and Emacs can obtain an access token from the OAuth
JD> provider to access the user data. Point.

TZ> You are asking the user to visit a URL (with `browse-url') with an
TZ> external web browser that can run Javascript, then maybe they get back
TZ> an auth code, and then they paste it back to Emacs.  The way you have
TZ> written oauth2.el, anyone that has customized `browse-url' to use w3m or
TZ> other non-Javascript browsers will not know that something went wrong.
TZ> Maybe oauth2.el should check for that case.

I've confirmed this is completely broken with w3m, at least.  I can't
even use the "OK" button in the displayed screen because oauth2.el is
waiting for me in the minibuffer, and of course w3m can't process the
form because it doesn't store cookies by default (I didn't go further in
the testing).  So please check that `browse-url' is not set to one of
the internal Emacs choices.

Thanks
Ted

Re: OAuth2 implementation in Elisp

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, Sep 27 2011, Ted Zlatanov wrote:

> I've confirmed this is completely broken with w3m, at least.  I can't
> even use the "OK" button in the displayed screen because oauth2.el is
> waiting for me in the minibuffer, and of course w3m can't process the
> form because it doesn't store cookies by default (I didn't go further in
> the testing).  So please check that `browse-url' is not set to one of
> the internal Emacs choices.

This does not look like it should be oauth2.el work to add workaround on
this.

Since it's likely that the Web page is a real web Page, what about
providing an Emacs function like `browse-url-with-a-capable-browser'
which would act like `browse-url' but will be defaulting to a capable
browser and will indicate to the user that it should not set this to
something that is not?

-- 
Julien Danjou

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: OAuth2 implementation in Elisp

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Tue, 27 Sep 2011 11:50:51 +0200 joakim@verona.se wrote: 
>
> j> Julien Danjou <julien@danjou.info> writes:
>
>>> I really doubt that:
>>> - it's easy to "click" on a JavaScript button from Emacs;
>
> j> Just for the record, this is possible in the xwidget branch!
>
> Is there a plan to merge that branch with the trunk?

Hopefully in the Emacs 25 timeframe, but the branch needs way more
testing. I'm using it as my main Emacs so it has okay stability now, but
it has only been tested on Fedora 15. Furthermore I've hand-waved a lot
of issues, so it needs some further quality improvements as well.

>
> Ted
>

-- 
Joakim Verona

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Tue, 27 Sep 2011 14:22:22 +0200 joakim@verona.se wrote: 

j> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Tue, 27 Sep 2011 11:50:51 +0200 joakim@verona.se wrote: 
>> 
j> Julien Danjou <julien@danjou.info> writes:
>> 
>>>> I really doubt that:
>>>> - it's easy to "click" on a JavaScript button from Emacs;
>> 
j> Just for the record, this is possible in the xwidget branch!
>> 
>> Is there a plan to merge that branch with the trunk?

j> Hopefully in the Emacs 25 timeframe, but the branch needs way more
j> testing. I'm using it as my main Emacs so it has okay stability now, but
j> it has only been tested on Fedora 15. Furthermore I've hand-waved a lot
j> of issues, so it needs some further quality improvements as well.

Thanks for explaining.  It sounds like the best approach to the OAuth2
problem.

Ted

Re: OAuth2 implementation in Elisp

[Ted Zlatanov]

On Tue, 27 Sep 2011 13:42:47 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Tue, Sep 27 2011, Ted Zlatanov wrote:
>> I've confirmed this is completely broken with w3m, at least.  I can't
>> even use the "OK" button in the displayed screen because oauth2.el is
>> waiting for me in the minibuffer, and of course w3m can't process the
>> form because it doesn't store cookies by default (I didn't go further in
>> the testing).  So please check that `browse-url' is not set to one of
>> the internal Emacs choices.

JD> This does not look like it should be oauth2.el work to add
JD> workaround on this.

Maybe, but it's the one that users will complain about :)

JD> Since it's likely that the Web page is a real web Page, what about
JD> providing an Emacs function like `browse-url-with-a-capable-browser'
JD> which would act like `browse-url' but will be defaulting to a capable
JD> browser and will indicate to the user that it should not set this to
JD> something that is not?

How about adding request capabilities, e.g. 

(with-browse-url-requirements '(javascript css)
 (browse-url the-url))

It could also be a browse-url argument I guess.

That would be a nice way to make it work for everyone...

Ted

Re: OAuth2 implementation in Elisp

[Richard Stallman]

One further problem with Javascript in web pages is that a lot of
it is nonfree software.  For that reason, I deactivate Javascript.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: OAuth2 implementation in Elisp

[Vijay Lakshminarayanan]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Why can't Emacs pretend to be a Web application?  Is it somehow less
> capable than other web browsers?

I have some experience with OAuth 1.0 but from what I've seen OAuth 2.0
is similar, at least in this aspect.

There are two kinds of OAuth consumers -- desktop and web.  In the case
of a Web consumer, we provide the OAuth provider (Google, Twitter etc)
with a callback URL to redirect users to after authentication.  For
Emacs to behave as a web app, it must (a) run a web-server (b) be
accessible via the internet.  Satisfying these two conditions is
practically impossible for all Emacs users.

In another thread of discussion, it appears that people are discussing
whether it's possible to render the URL with the application code
/within/ Emacs.  This is a better goal, IMO.

> Thanks
> Ted

-- 
Cheers
~vijay

Gnus should be more complicated.