OAuth for Common Lisp
Common Lisp Shell
Latest commit a7a463c Jul 14, 2015 @skypher Merge pull request #22 from masatoi/master
Added headers to return values of ACCESS-PROTECTED-RESOURCE.

README

This is cl-oauth, an implementation of the OAuth 1.0a standard
in Common Lisp.

Spec URI: http://oauth.net/core/1.0a

Section numbers mentioned in the code and documentation
refer to this document, unless mentioned otherwise.

Most of the code has passed basic manual and automated tests,
but the SP code hasn't been used in a real-world application
yet.


Not supported at this time:

Service Provider:

  * parameters from Auth header (needs some parsing) [5.4]
    in principle a MUST, but as SP you get to decide ;)

  * Nonce checking [9], a SHOULD.

  * Session extension
      http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html
  
  * Problem Reporting extension
      http://oauth.pbworks.com/ProblemReporting

Consumer:

  * Auth parameters should be working, but Google rejects them for
    some reason. Do more testing and debugging.

  * Revoking tokens as per section 7 of the Session extension

  * Problem Reporting extension: fields in body are ignored.

Both:

  * crypto signatures different from HMAC-SHA1. It's easy to use
    other digests and MACs via Ironclad but RSA needs to have
    padding implemented. [9.3]

  * PLAINTEXT signature. Meh. [9.4]

  * POST and Auth requests are hardly tested yet.


People who contributed in a substantial way to this library:

  * Leslie P. Polzer <polzer@port-zero.com>: base implementation.

See also revision log for minor contributions.


TODO (apart from spec things not implemented yet):

  * grep the code for TODO and FIXME

  * incorporate test cases from http://wiki.oauth.net/TestCases

  * abstract token storage, can't get far with volatile memory
    FETCH-TOKEN/STORE-TOKEN

  * better handling of different protocol versions; in particular
    we should support serving both 1.0 and 1.0a clients (and requesting
    stuff from 1.0 and 1.0a servers too, of course).

  * compare with the Hammer draft spec and resolve differences

  * always store the URL-decoded key/secret in the request token