Investigate making OAuth 1.0a signed requests from the browser

[easoncxz]

Browsers can't keep an OAuth 1.0a "Consumer Secret" secret, so there may be implications about whether it's a good idea (or even possible, due to concerns like CORS) to attempt to make OAuth 1.0a requests from a browser.

Find out whether to do OAuth-signing in the browser or on the server.

Related reading:

• OAuth's website, listing some OAuth client/consumer software: https://oauth.net/1/
  • which includes this oauth-1.0a npm package, which looks like it can be run in the browser.
• Twitter docs on creating a signature, which uses both the consumer secret and access token secret as parts of the same signing key: https://developer.twitter.com/en/docs/authentication/oauth-1-0a/creating-a-signature

[easoncxz]

It's really tricky; the Twitter docs don't say what format parameters should be sent in --- application/x-www-form-urlencoded or application/json or query-string?

• POST statuses/update

And on the other hand, oauth-1.0a doesn't say what format their RequestOptions?.data field should be. The .d.ts provided along with the library says:

  /**
   * Request options.
   */
  export interface RequestOptions {
    url: string;
    method: string;
    data?: any;
    includeBodyHash?: boolean;
  }

any!!

It'll be necessary to either dig through docs, or look at working libraries to figure out what's going on.

Reading list:

• node-fetch, which I'm not using directly: https://github.com/node-fetch/node-fetch
  • a FormData library: https://github.com/octet-stream/form-data
• MDN docs on fetch: https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
  • MDN on FormData: https://developer.mozilla.org/en-US/docs/Web/API/FormData
• fetch cheatsheet: https://devhints.io/js-fetch

[easoncxz]

Ok here's the plan:

• Use the oauth aka node-oauth npm package to make some OAuth POST-with-body requests to Twitter, and see things work.
• Point the working OAuth 1.0a authenticated POST request to a local http-echo-server, and basically reverse-engineer out exactly what format the POST params are sent through --- as a JSON string body, as form-urlencoded, or as query-string params.
• Then adapt the working solution into the browser via one of the following two ways:
  • Craft the correct input for the oauth-1.0a (github) library to produce the correct HTTP header string, then craft an exactly-the-same HTTP request using fetch.
  • Someone just bundle the oauth npm package to be run inside my browser.

[easoncxz]

Reasonable progress so far. Commit 54e70e5f successfully sent tweets:

• https://twitter.com/easoncxz/status/1300391856316903424

Related Twitter documentation:

• https://developer.twitter.com/en/docs/twitter-api/v1/tweets/post-and-engage/api-reference/post-statuses-update

It seems unnecessary to continue with the plan with reverse-engineering using http-echo-server, because the implementation using node-oauth is explicit enough that I feel pretty confident. There are basically two options for Twitter v1.1 API's POST endpoints:

• Content-Type: application/json
• Content-Type: application/x-www-form-urlencoded

Next time it would be reasonable to attempt to implement the same thing using fetch via some kind of fetch library.

[easoncxz]

Just one more step before this issue can be closed:

• [x] Run the same fetch workflow that's already working, but in the browser instead of in NodeJS.

Edit: abandoning this check-box. I want people to be able to use my app, while not leaking my Consumer credentials. See #5 for continuation.