Thanks for the prototype code. The OpenID framework is overkill for
authentication that commits to trusting one particular counterparty, so
I'd rather see a simpler implementation from scratch. I'm not sure it's
worth implementing anything beyond the latest version of the OAuth protocol.
On 11/21/2015 06:17 AM, 1337 777 wrote:
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
