On Sun, Aug 25, 2013 at 10:58 AM, Steve Holme <steve_holme_at_hotmail.com> wrote:

>> > Do you know if OAUTH 2.0 is supported in POP3 as well?
>>
>> POP3 might support OAUTH 2.0, but I have not found a provider
>> that has implemented it. I know that presently the google POP3
>> service does not support OAUTH 2.0.
>
> I couldn't find much on the subject myself, from a quick search, but I think
> I found a mail client / api that had implemented it and it should be pretty
> straight forward to implement it here as well.

I plan to focus on the HTTP Authorization XOAUTH2 mechanism in the
near future, I could attempt to address the POP3 implementation at
that time. I will have to do some digging to find a provider that I
can test it with.

> Mmmm... I don't know of a way of doing this from that function myself and it
> does worries me that --bearer needs to be specified before -u to avoid the
> user being prompted for the password :(
>
> Perhaps the call to checkpasswd() could be moved to after all the parameters
> have been got ??
>
> You also need to bear in mind that checkpasswd() doesn't just check for the
> password - it also looks for the optional login options via the ; separator
> which is currently used to specify the preferred authentication mechanism
> (in addition to in the URL). As such we should support "-bearer mybearer -u
> steve;AUTH=XOAUTH2" as a valid command line to curl. If bearer was passed
> into this function then it could be added to the check that then requests
> the password from the user.

Perhaps in addition to moving the call to checkpassword() to after the
parameter collection it might be intuitive to add a new type to
checkpasswd() - say, "XOAUTH2 Access Token" - to prompt for an omitted
bearer. This would handle cases where the auth mech was explicitly
defined as AUTH=XOAUTH2, but no bearer token was provided.

Below is an example of the behavior of a few examples with the
included patches. Hopefully this gives you a better context of the
current behavior.

command: curl --url "smtps://smtp.domain.com:465" -u
user.name_at_domain.com --bearer ya29.AHES...xMbS
result: prompts for password; user can enter anything and OAUTH
proceeds normally

command: curl --url "smtps://smtp.domain.com:465" -u
user.name_at_domain.com;AUTH=XOAUTH2 --bearer ya29.AHES...xMbS
result: prompts for password; auth LOGIN is attempted

command: curl --url
"smtps://user.name;AUTH=XOAUTH2_at_smtp.domain.com:465" --bearer
ya29.AHES...xMbS
result: no prompt for password; OAUTH proceeds normally

> I'm pretty happy with the patches myself - although I did want to ask /
> point out the following before committing:
>
> * Is it necessary to obtain the length of user and bearer (ulen and blen) in
> Curl_sasl_create_xoauth2_message() in order to calculate the length that is
> passed to Curl_base64_encode() - could this be strlen(xoauth) or have I
> missed something there?

No, you are correct. After ditching the stack based buffer I
overlooked this. tunnel vision... This has been corrected in the
attached patch.

> * Setting outlen and outptr are not, strictly speaking, needed when
> returning failure

Changed. Both conventions were present in the same file, I erred on
the side of specificity.

> * The alignment of the parameters to the function are also 2 characters out
> in the .c file

Fixed.

Also, I removed the check for conn->bearer from the functions
imap_perform_authenticate and smtp_perform_authenticate, as I believe
this check lacks sanity. With that check If the bearer is absent the
result would is "No known authentication mechanisms supported!", which
I believe should result in code 334 "Authentication Failure". Any
check for the bearer should be done elsewhere (if at all).

Regards,

-- 
Kyle L. Huff
http://curetheitch.com
http://webpg.org

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html