99designs / http-signatures-php Goto Github PK
View Code? Open in Web Editor NEWSign and verify PSR-7 HTTP messages in PHP.
License: MIT License
Sign and verify PSR-7 HTTP messages in PHP.
License: MIT License
Currently, many error conditions are thrown as Exception
.
Instead they should be made more specific, all inheriting from a central library-specific base exception.
See https://github.com/99designs/http-signatures-ruby for reference.
Hi, I'm @msporny, primary author of the HTTP Signatures specification at IETF for many years now. You've implemented some variation of that specification.
I need your help to move that specification towards a global standard at IETF. Hearing from implementers, such as you, is a big part of determining if the work toward a global standard should proceed. The IETF HTTP Working Group is determining whether the work should proceed right now. This is very good news, because the European Banking API community, W3C DID Working Group, W3C Credentials Community Group and other standards setting organizations depend on implementations standardizing on a way to do HTTP Signatures.
The deadline for noting your support is Jan 31st 2020 (in ~10 days).
Here's where you can make a difference...
Here is the IETF HTTP WG Call for Adoption:
https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0002.html
To note your support of the specification:
For an example of the type of email you could write, see this:
https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0018.html
Thanks a ton for supporting the specification through your implementation. I hope you consider helping us take the specification across the goal line by voicing your support in the IETF HTTP Working Group!
Need to enhance the Digest creation/validation functions to account for multiple digests in a single header. Will work on an implementation and submit PR shortly.
See #28 for what prompted this.
We're currently using a double HMAC approach for signature comparison, as that was the only way for us to securely compare HMAC signatures without making it a breaking change, as the hash_equals function we need isn't available until PHP 5.7, and we support PHP 5.5+
When we roll out our next major version we should increase the minimum PHP version to 5.7 or higher, and swap to using hash_equals
.
These two headers have different meanings and intentions, and it may not be safe to simply issue both for all requests.
PR #36 implements separate sign
and authorize
methods to generate these headers individually.
Specification allows messages to omit the "headers" signature parameter, requiring signers and validators to use the implicit value date
instead. Presently this library cannot handle this.
Implemented in PR #42
The Signing HTTP Messages draft standard illustrates how to include other headers, specifically including the Digest header in the signature string. Very many sites using HTTP Signatures now incorporates this technique as standard (a good thing).
#38 adds the public function signWithDigest($message)
that calls private function addDigest($message)
to:
It looks like this library currently only supports HMAC signing. It would be great if it also supported RSA signing with a private key!
Recently, we used this library in Projects for signing requests to external apis within the contests stack. It was slightly confusing to begin with, as currently this library is designed to use Symfony's HttpFoundation\Request
class for both signing and verifying messages.
The Symfony Request class is supposed to be used as a representation of the request that is coming into your Symfony/Silex/etc stack, rather than being a request sent to another stack.
This doesn't fit very well for the use case of making requests between services, as this is generally done using Guzzle, which has its own class for representing the request it will send.
To get around this issue, I manually created and signed a Symfony Request and then used its headers as arguments to the Guzzle request when creating it.
This code can be seen in our ContestsApiClient
here
This library should be able to sign a Guzzle request
$request = $guzzleClient->createRequest($method, $url, [
'Date' => 'Wed, 30 Jul 2014 16:40:19 -0700',
'Accept' => 'llamas',
]);
$context->signer()->sign($request);
The server should be able to require the client to sign certain headers, and reject any messages in which these headers are unsigned.
For example, a server should be able to require a signed digest
header for POST requests, and reject any message that doesn't have a signed digest header.
This protects against sloppy clients "leaving the door open": if a POST request with an unsigned digest is intercepted, the message body can be manipulated without invalidating the signature, and the forged message would be accepted.
This could be prevented by supplying a list of required headers to the constructors of the Verifier and Verification classes.
It might be useful to supply two sets of headers, one for requests without a body, and another for messages with a body. (Note that DELETE requests may or may not have a body).
For reference: https://datatracker.ietf.org/doc/html/rfc9421#verify-requirements
@mtibben says:
@pda: you may want to consider using PSR7 Request rather than Symfony Requests for that lib
http://www.php-fig.org/psr/psr-7/
That PSR-7 page describes a Psr\Http\Message\RequestInterface
. Maybe worth noting it also says:
An HTTP client MUST ignore the values of
Uri::getPath()
andUri::getQuery()
, and instead use the value returned bygetRequestTarget()
, which defaults to concatenating these two values.
Also, I regret not wrapping whatever request object in a locally-defined interface, making issues like #8 much harder to solve. So a breaking change version of this library would probably introduce a new Message
interface with a SymfonyReqestMessage
and PSR7RequestMessage
implementation.
The latest version of the spec is quite a bit different:
I'm trying to use this with a js library (https://github.com/dhensby/node-http-message-signatures/), but can't since the specs don't agree.
I can try to work on a PR if I have time, but wanted to check in and see if this project was still maintained and if you'd be open to supporting the newer spec.
Copied from 99designs/http-signatures-ruby#10
Currently key rotation is difficult; the verifier needs to start verifying with the new key at the same moment the new key is used by the signer. In a high-traffic environment this can be near impossible without dropping requests.
It should be possible to pass multiple keys to the verifier, so that both old and new keys can be accepted for a period of time. Either N keys, or a static limit of two keys (current and previous) would work.
This could be represented by passing an array of keys per ID; using the first for signing, and using all of them for verification. Or⦠something else?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.