Permalink
Browse files

update basho fork from main mochiweb repo

  • Loading branch information...
2 parents 50695ad + e6d1870 commit eadb14b94df088deca8eeec3655b660a534e8e79 @vinoski vinoski committed Oct 28, 2011
Showing with 5,052 additions and 700 deletions.
  1. +9 −2 .gitignore
  2. +7 −0 .travis.yml
  3. +29 −0 CHANGES.md
  4. +19 −7 Makefile
  5. +16 −0 README
  6. +0 −42 ebin/mochiweb.app
  7. +206 −0 examples/hmac_api/README
  8. +43 −0 examples/hmac_api/hmac_api.hrl
  9. +34 −0 examples/hmac_api/hmac_api_client.erl
  10. +435 −0 examples/hmac_api/hmac_api_lib.erl
  11. +146 −0 examples/https/https_store.erl
  12. +19 −0 examples/https/server_cert.pem
  13. +27 −0 examples/https/server_key.pem
  14. +81 −0 examples/keepalive/keepalive.erl
  15. BIN rebar
  16. +15 −3 rebar.config
  17. +45 −0 scripts/entities.erl
  18. +10 −14 scripts/new_mochiweb.erl
  19. +1 −1 src/mochifmt.erl
  20. +1 −1 src/mochifmt_records.erl
  21. +1 −1 src/mochifmt_std.erl
  22. +2 −2 src/mochiglobal.erl
  23. +1 −1 src/mochihex.erl
  24. +1 −1 src/mochijson.erl
  25. +131 −22 src/mochijson2.erl
  26. +1 −1 src/mochilists.erl
  27. +4 −4 src/mochilogfile2.erl
  28. +51 −28 src/mochinum.erl
  29. +2 −1 src/mochitemp.erl
  30. +15 −14 src/mochiutf8.erl
  31. +9 −0 src/mochiweb.app.src
  32. +19 −27 src/mochiweb.erl
  33. +4 −2 src/mochiweb_acceptor.erl
  34. +2,131 −256 src/mochiweb_charref.erl
  35. +20 −5 src/mochiweb_cookies.erl
  36. +1 −1 src/mochiweb_cover.erl
  37. +9 −6 src/mochiweb_echo.erl
  38. +3 −3 src/mochiweb_headers.erl
  39. +216 −11 src/mochiweb_html.erl
  40. +52 −78 src/mochiweb_http.erl
  41. +1 −4 src/mochiweb_io.erl
  42. +360 −39 src/mochiweb_mime.erl
  43. +64 −16 src/mochiweb_multipart.erl
  44. +141 −22 src/mochiweb_request.erl
  45. +152 −0 src/mochiweb_request_tests.erl
  46. +1 −1 src/mochiweb_response.erl
  47. +129 −53 src/mochiweb_socket_server.erl
  48. +68 −29 src/mochiweb_util.erl
  49. +2 −2 src/reloader.erl
  50. +5 −0 support/templates/.gitignore
  51. +22 −0 support/templates/mochiwebapp.template
  52. +8 −0 support/templates/mochiwebapp_skel/priv/www/index.html
  53. +7 −0 support/templates/mochiwebapp_skel/rebar.config
  54. +9 −0 support/templates/mochiwebapp_skel/src/mochiapp.app.src
  55. +30 −0 support/templates/mochiwebapp_skel/src/mochiapp.erl
  56. +22 −0 support/templates/mochiwebapp_skel/src/mochiapp_app.erl
  57. +84 −0 support/templates/mochiwebapp_skel/src/mochiapp_deps.erl
  58. +56 −0 support/templates/mochiwebapp_skel/src/mochiapp_sup.erl
  59. +69 −0 support/templates/mochiwebapp_skel/src/mochiapp_web.erl
  60. +6 −0 support/templates/mochiwebapp_skel/start-dev.sh
View
@@ -1,2 +1,9 @@
-ebin
-.eunit
+/ebin
+/doc
+/_test
+/.eunit
+/docs
+.DS_Store
+/TEST-*.xml
+/deps
+*.swp
View
@@ -0,0 +1,7 @@
+language: erlang
+notifications:
+ email: false
+otp_release:
+ - R14B03
+ - R14B02
+ - R14B01
View
@@ -0,0 +1,29 @@
+Version 2.3.0 released 2011-10-14
+
+* Handle ssl_closed message in mochiweb_http (#59)
+* Added support for new MIME types (otf, eot, m4v, svg, svgz, ttc, ttf,
+ vcf, webm, webp, woff) (#61)
+* Updated mochiweb_charref to support all HTML5 entities. Note that
+ if you are using this module directly, the spec has changed to return
+ `[integer()]` for some entities. (#64)
+
+Version 2.2.1 released 2011-08-31
+
+* Removed `mochiweb_skel` module from the pre-rebar era
+
+Version 2.2.0 released 2011-08-29
+
+* Added new `mochiweb_http:start_link/1` and
+ `mochiweb_socket_server:start_link/1` APIs to explicitly start linked
+ servers. Also added `{link, false}` option to the `start/1` variants
+ to explicitly start unlinked. This is in expectation that we will
+ eventually change the default behavior of `start/1` to be unlinked as you
+ would expect it to. See https://github.com/mochi/mochiweb/issues/58 for
+ discussion.
+
+Version 2.1.0 released 2011-08-29
+
+* Added new `mochijson2:decode/2` with `{format, struct | proplist | eep18}`
+ options for easy decoding to various proplist formats. Also added encoding
+ support for eep18 style objects.
+
View
@@ -1,16 +1,28 @@
-all: compile
-compile:
- ./rebar compile
+PREFIX:=../
+DEST:=$(PREFIX)$(PROJECT)
+
+REBAR=./rebar
+
+all:
+ @$(REBAR) get-deps compile
edoc:
- ./rebar doc
+ @$(REBAR) doc
test:
- ./rebar eunit
+ @rm -rf .eunit
+ @mkdir -p .eunit
+ @$(REBAR) skip_deps=true eunit
clean:
- ./rebar clean
+ @$(REBAR) clean
+
+build_plt:
+ @$(REBAR) build-plt
dialyzer:
- ./rebar analyze
+ @$(REBAR) dialyze
+
+app:
+ @$(REBAR) create template=mochiwebapp dest=$(DEST) appid=$(PROJECT)
View
16 README
@@ -1 +1,17 @@
MochiWeb is an Erlang library for building lightweight HTTP servers.
+
+The latest version of MochiWeb is available at http://github.com/mochi/mochiweb
+
+The mailing list for MochiWeb is at http://groups.google.com/group/mochiweb/
+
+R12B compatibility:
+The master of MochiWeb is tested with R14A and later. A branch compatible
+with R12B is maintained separately at http://github.com/lemenkov/mochiweb
+The R12B branch of that repository is mirrored in the official repository
+occasionally for convenience.
+
+To create a new mochiweb using project:
+ make app PROJECT=project_name
+
+To create a new mochiweb using project in a specific directory:
+ make app PROJECT=project_name PREFIX=$HOME/projects/
View
@@ -1,42 +0,0 @@
-{application, mochiweb,
- [{description, "MochiMedia Web Server"},
- {vsn, "1.7.1"},
- {modules, [
- mochifmt,
- mochiglobal,
- mochihex,
- mochijson,
- mochijson2,
- mochilists,
- mochilogfile2,
- mochinum,
- mochitemp,
- mochiutf8,
- mochiweb,
- mochiweb_acceptor,
- mochiweb_app,
- mochiweb_charref,
- mochiweb_cookies,
- mochiweb_cover,
- mochiweb_echo,
- mochiweb_headers,
- mochiweb_io,
- mochiweb_html,
- mochiweb_http,
- mochiweb_mime,
- mochiweb_multipart,
- mochiweb_request,
- mochiweb_response,
- mochiweb_skel,
- mochiweb_socket,
- mochiweb_socket_server,
- mochiweb_sup,
- mochiweb_util,
- reloader,
- mochifmt_std,
- mochifmt_records
- ]},
- {registered, []},
- {mod, {mochiweb_app, []}},
- {env, []},
- {applications, [kernel, stdlib]}]}.
View
@@ -0,0 +1,206 @@
+Introduction
+------------
+
+This example shows how to make an Amazon-style HMAC authentication system for an API with mochiweb.
+
+Purpose
+-------
+
+The purpose of this example is to:
+* make it easy to implement an API in mochiweb
+ - using a proven approach so that 'amateurs' don't have to reinvent crypto
+* make it easy to generate client libraries for that API so that client-side implementers can:
+ - reuse closely related code examples
+ - build compatibility unit tests instead of fiddling around debugging their library against live implementations of the system
+
+Scope
+-----
+
+The scope of this document is:
+* a description of the client-server exchange
+* a reference implementation of
+ - the server-side implementation of the exchange
+ - the client-side implementation of the exchange
+* developing a custom implementation of an API
+* deploying that implementation to new client-side users to build their client libraries
+
+Contents
+--------
+
+Subsequent sections of this document are:
+* the client-server exchange
+* the reference implementation in this example
+* building a custom implementation
+* deploying a custom implementation
+
+The Client-Server Exchange
+--------------------------
+
+OVERVIEW
+
+This section describes the client-server exchange for an Amazon-style API authentication schema. It has the following characteristics:
+* based on a public key/private key
+* used to authenticate non-SSL api requests
+* not a full once-use schema and is vulnerable to replay attacks within a short time window
+
+TYPE OF API
+
+The api described in this document is:
+* suitable for machine-machine communication
+
+The api described in this document is NOT:
+* an implementation of 2-legged OAUTH
+ - see https://github.com/tim/erlang-oauth
+* an implementation of 3-legged OAUTH
+
+It is not suitable for use in applications where an end user has to log into a service and piggy-back on top of a keypair security system.
+
+THE CLIENT LIBRARY HERE IS **NOT** AN AMAZON CLIENT LIBRARY. AMAZON DOES FUNKY STUFF WITH HOSTNAMES AND PUSHES THEM ONTO THE URL IN CANONICALIZATION! THE CLIENT LIBRARY IS AMAZON-A-LIKE ENOUGH TO USE THE AMAZON DOCOS TO BUILD A TEST SUITE.
+
+STEP 1
+
+The client is issued with a pair of keys, one public, one private, for example:
+* public: "bcaa49f2a4f7d4f92ac36c8bf66d5bb6"
+* private: "92bc93d6b8aaec1cde772f903e06daf5"
+
+In the Amazon docs these are referred to as:
+* AWSAccessKeyId (public)
+* AWSSecretAccessKey (private)
+
+These can be generated by the function:
+hmac_api_lib:get_api_keypair/0
+
+This function returns cryptographically strong random numbers using the openSSL crypto library under the covers.
+
+The public key is used as a declaration of identity, "I am bcaa49..."
+
+The private key is never passed over the wire and is used to construct the same hash on both the client- and the server-side.
+
+STEP 2
+
+The client prepares their request:
+* url
+* time of request
+* action (GET, POST, etc)
+* type of request (application/json, etc)
+* contents of request
+* etc, etc
+
+These components are then turned into a string called the canonical form.
+
+The HTTP protocol is permissive; it treats different requests as if they were the same. For instance it doesn't care about the order in which headers are sent, and allows the same header to contain multiple values as a list or be specified multiple times as a key-value pair.
+
+Intermediate machines between the client and server MAY pack and repack the HTTP request as long as they don't alter its meaning in a narrow sense. This means that the format of the HTTP request is not guaranteed to be maintained.
+
+The canonical form simply ensures that all the valid ways of making the same request are represented by the same string - irrespective of how this is done.
+
+The canonical form handles POST bodies and query parameters and silently discards anchors in URL's.
+
+A hash of this string is made with the private key.
+
+STEP 3
+
+The client makes the request to the server:
+* the signature is included in the request in the standard HTTPAuthorization header. (As the Amazon documentation points out this is infelicitous as it is being used for Authentication not Authorization, but hey!).
+
+The Authorization header constructed has the form:
+<schema name><space><public key><colon><signature>
+
+An Amazon one looks like:
+Authorization: AWS 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
+ --- -------------------- ----------------------------
+ sch public key signature
+
+The HTTP request is made.
+
+STEP 4
+
+The request is processed:
+* the server receives the request
+* the server constructs the canonical form from the attributes of the request:
+ - url
+ - date header
+ - action (GET, POST, etc)
+ - content type of request (application/json, etc)
+ - some custom headers
+ - etc, etc
+* the server takes the client's public key from the HTTPAuthorization header and looks up the client's private key
+* the server signs the canonical form with the private key
+* the server compares:
+ - the signature in the request to the signature it has just generated
+ - the time encoded in the request with the server time
+* the request is accepted or denied
+
+The time comparison is 'fuzzy'. Different server's clocks will be out of sync to a degree, the request may have acquired a time from an intermediate machine along the way, etc, etc. Normally a 'clock skew' time is allowed - in Amazon's case this is 15 minutes.
+
+NOTA BENE: THIS CLOCK SKEW TIME ALLOWS FOR REPLAY ATTACKS WHERE A BAD GUY SIMPLY CAPTURES AND REPLAYS TRAFFIC.
+
+EXTENSION
+
+It is possible to extend this schema to prevent replay attacks. The server issues a nonce token (a random string) which is included in the signature. When the server authorizes the request it stores the token and prevents any request with that token (ie a replay) being authorized again.
+
+The client receives its next nonce token in the response to a successful request.
+
+The Reference Implementation In This Example
+--------------------------------------------
+
+The reference implementation used in this example is that described in the Amazon documentation here:
+http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAuthentication.html
+
+The try out the reference implementation:
+* create a new mochiweb project as per the mochiweb README
+ - make app PROJECT=project_name
+* copy hmac_api_lib.erl and hmac_api_client.erl into project_name/src
+* copy hmac_api.hrl into project_name/include
+* edit project_name_web.erl and add a call to hmac_api_lib:authorize_request/1
+
+authorize/request/1 should be called in the loop of project_name_web.erl as per:
+
+ loop(Req, DocRoot) ->
+ Auth = hmac_api_lib:authorize_request(Req),
+ io:format("Auth is ~p~n", [Auth]),
+ "/" ++ Path = Req:get(path),
+ ...
+
+When this is done you are ready to test the api:
+* run 'make' in project_name/ to build the Erlang
+* start the web server with 'start-dev.sh' in project_name/ (this will also open an Erlang shell to the Erlang VM)
+
+To test the api run this command in the Erlang shell:
+* hmac_api_client:fire().
+
+The reference implementation uses 5 constants defined in hmac_api.hrl.
+* schema
+* headerprefix
+* dateheader
+* publickey
+* privatekey
+
+Building A Custom Implementation
+--------------------------------
+
+The simplest custom implementation is to simply take the existing code and change the values of the following constants:
+* schema
+* headerprefix
+* dateheader
+
+If the API is to be used 'as is', please use the values which are commented out in hmac_api.hrl. This will make easier for software developers to work out which version of which client-side libraries they can use.
+
+Client libraries written in other languages than Erlang can reemployment the test suite in hmac_api_lib.erl.
+
+More sophisticated changes will involve changes to the canonicalization functions.
+
+Use of a generic schema should make reuse of client libraries easier across different platforms.
+
+If you develop an ‘as-is’ client-side library in another language please consider submitting its code to this example.
+
+Deploying A Custom Implementation
+---------------------------------
+
+When deploying a custom implementation, the server-side code should be released with unit tests so the client-side developer can easily build a robust client.
+
+In addition to that you will need to specify:
+* description of how the API works:
+ - ie the acceptable methods and urls
+ - custom headers and their usage (if appropriate)
+
@@ -0,0 +1,43 @@
+-author("Hypernumbers Ltd <gordon@hypernumbers.com>").
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%% %%%
+%%% Reference values for testing against Amazon documents %%%
+%%% %%%
+%%% These need to be changed in production! %%%
+%%% %%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+-define(schema, "AWS").
+%% defines the prefix for headers to be included in the signature
+-define(headerprefix, "x-amz-").
+%% defines the date header
+-define(dateheader, "x-amz-date").
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%% %%%
+%%% Default values for defining a generic API %%%
+%%% %%%
+%%% Only change these if you alter the canonicalisation %%%
+%%% %%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%-define(schema, "MOCHIAPI").
+%%-define(headerprefix, "x-mochiapi-").
+%%-define(dateheader, "x-mochiapi-date").
+
+%% a couple of keys for testing
+%% these are taken from the document
+%% % http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAuthentication.html
+%% they are not valid keys!
+-define(publickey, "0PN5J17HBGZHT7JJ3X82").
+-define(privatekey, "uV3F3YluFJax1cknvbcGwgjvx4QpvB+leU8dUj2o").
+
+
+-record(hmac_signature,
+ {
+ method,
+ contentmd5,
+ contenttype,
+ date,
+ headers,
+ resource
+ }).
Oops, something went wrong.

0 comments on commit eadb14b

Please sign in to comment.