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 https://github.com/1337777/oauth http://hg.impredicative.com/openid
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 <[email protected]> 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 <[email protected]> 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) _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
