The Signer class is designed for those who are signing data on behalf of a public-private keypair.

In principle, the "client party" has public key (i.e., client_id) and a matching private key (i.e., client_secret) that can be verified by both the signer and the client (but nobody else as we don't want to make forgeries possible).

The "signing party" has a simple identifier which acts as an additional piece of entropy in the algorithm, and can help differentiate between multiple signing parties if the client party does something like try to use the same public-private keypair independently of a signing party (as is common with GPG signing).

Based on a simplified version of the AWS Signature v4.

This project uses Semantic Versioning for managing backwards-compatibility.

NOTE: To use this gem alongside the wepay gem, the wepay gem MUST be at least version 0.2.0.

• API Reference

(Using word_wrap() for line wrapping.)

client_id = 'your_client_id'
client_secret = 'your_client_secret'

signer = WePay::Signer.new(client_id, client_secret)
signature = signer.sign({
  :token        => your_token,
  :page         => wepay_page_to_visit,
  :redirect_uri => partner_page_to_return_to,
})

puts signature.word_wrap(64)
#=> dfbffab5b6f7156402da8147886bba3eba67bd5baf2e780ba9d39e8437db7c47
#=> 35e9a0b834aa21ac76f98da8c52a2a0cd1b0192d0f0df5c98e3848b1b2e1a037

querystring = signer.generate_query_string_params({
  :token        => your_token,
  :page         => wepay_page_to_visit,
  :redirect_uri => partner_page_to_return_to,
})

#=> client_id=your_client_id&
#=> page=https://wepay.com/account/12345&
#=> redirect_uri=https://partnersite.com/home&
#=> token=dfbffab5b6f7156402da8147886bba3eba67bd5baf2e780ba9d39e8437db7c47...

gem 'wepay-signer'

And include it in your scripts:

require 'wepay-signer'

Firstly, run bundle install to download and install the dependencies.

You can run the tests as follows:

make test

The API Reference is generated by a tool called YARD. Once it's installed, you can generate updated documentation by running the following command in the root of the repository.

make docs

1. The Makefile (yes, Makefile) has a series of commands to simplify the development and deployment process.
2. Also install Chag. This is used for managing the CHANGELOG and annotating the Git release correctly.

Make sure that the CHANGELOG.md is human-friendly. See http://keepachangelog.com if you don’t know how.

Running make by itself will show you a list of available sub-commands.

$ make
all
docs
gem
install
pushdocs
pushgem
tag
test
version

You will need to have write-access to the wepay/signer-ruby repository on GitHub. You should have already set up:

• Your SSH key with your GitHub account.
• Had your GitHub user given write-access to the repository.

Then you can run:

make pushdocs

You can view your changes at https://wepay.github.io/signer-ruby/.

You will need to have pulled-down the proper gem credentials first. When prompted, enter your RubyGems password.

Login and view your RubyGems profile page to see the proper command.

Then you can run:

make pushgem

If you need to add an additional gem owner:

gem owner wepay -a api@wepay.com

You can view your changes at https://rubygems.org/gems/wepay-signer.

This will leverage Chag to generate a commit for the tag. Then you can run:

make tag

1. Go to https://github.com/wepay/signer-ruby/tags
2. Find the new tag that you just pushed. Click the ellipsis (…) to see the commit notes. Copy these.
3. To the right, choose Add release notes. Your Tag version should be pre-filled.
4. The Release title should match your Tag version.
5. Inside Describe this release, paste the notes that you copied on the previous page.
6. Choose Publish release.
7. Your release should now be the latest. https://github.com/wepay/signer-ruby/releases/latest

Here's the process for contributing:

1. Fork Signer to your GitHub account.
2. Clone your GitHub copy of the repository into your local workspace.
3. Write code, fix bugs, and add tests with 100% code coverage.
4. Commit your changes to your local workspace and push them up to your GitHub copy.
5. You submit a GitHub pull request with a description of what the change is.
6. The contribution is reviewed. Maybe there will be some banter back-and-forth in the comments.
7. If all goes well, your pull request will be accepted and your changes are merged in.

• Copyright (c) 2015-2016 WePay

See also the list of contributors who participated in this project.

Licensed for use under the terms of the Apache 2.0 license.