[Ur] The right way to do federated login in 2015?

1337 777 1337777.net at gmail.com
Sat Nov 21 06:17:09 EST 2015

Here is some working oauth source code which get the userinfo api of
the author, this is some copy-paste duplicate on the side of the
openid source code for easy comparison, no trimming out

It is not technical but it is minimal and necessary and it takes
someone to take the time to type on the keyboard and resolve
ridiculuous bugs
... example: github require some user-agent header and this must be
done in curl with CURLOPT_USERAGENT not with CURLOPT_HTTPHEADER ..
github does not accept SSLv3 and this must be erased from the curl call
github gives the response of curl POST access_token in urlencoded    =
and &    form but the original OpenidFFi.direct was parsing the
response using    : and \newline
github maybe has some bug during the authorization code exchange
because this must be tried 2 times to get success access_token

...the oauth interface of google has the same form so this source code
shall be ok with google

kthxby now COQ

On Thu, Nov 19, 2015 at 4:17 PM, 1337 777 <1337777.net at gmail.com> wrote:
> After reviewing
> http://hg.impredicative.com/openid
> The only programmation thing which is extra beyond OAUTH is:
> * temporarily storing the connection ("endpoint") tools:
>     + dh secret exchange when not on httpS
>     + enciphering/deciphering the hmac key using the dh secret
>     + signing/verifying the connection data using this hmac key
> * permanentlly storing the pairing of "user" profile with "identifier"
> Therefore maybe some boring 3-hours trimming out of the texts of the
> connection tools and the user-identifier pairing, without touching
> anything else, shall give OAUTH... so what sense exactly is "some
> oauth library" ?
> hmmmm.. I have this OAUTH schema in mind for
> https://developer.github.com/v3/oauth/
> authorize
>     ->GET redirect_uri stIdx, state, (scope)
> ~~Basis.redirect()/FFi.indirect()
> redir_uri stIdx
>     <-BACK code/identifier, state, [cookie]
>     ->RPOST code/identifier, client_secret        ~~FFi.discovery()/FFi.direct()
>     <-HTML token/endpoint, (token_scope, token_type)
> apiform
>     ->POST api_uri, token/endpoint
>     <-HTML user
> seq0: {stateIndex}
> tab1: {stateIndex, state, option code/identifier, code_scope,
> expirity, option (token/endpoint * token_scope * token_type)}
> cookie: {stateIndex, state}
> ...
> (ok ok ... I was putting on hold my coq proof of the biassociative
> coherence, now I will write it before December 4 and publish somewhere
> else just to be annoying)
> On Thu, Oct 22, 2015 at 10:37 PM, 1337 777 <1337777.net at gmail.com> wrote:
>>> I'm motivated enough about at least the OAuth part, as I want to use
>>> it for a web app, aimed at developers, to do login with GitHub
>>> credentials.  So, I expect that bit would get done by early 2016, even
>>> if no one else volunteers.
>> how is this different than doing the crypto-signing/verifying
>> mathematics not in the browser but behind some web interface ?
>> Ultimately this is the genre of programming activity that I may do in
>> the near future for some concurrent web app, therefore "I"😏 may as
>> well start now until someone else is quicker ? (part-timing from
>> readying for the univalent-foundations workshop this may 16-20 at the
>> fields institute)

More information about the Ur mailing list