mirror of https://gitlab.com/bashrc2/epicyon
Separate sections
parent
4c4c17730a
commit
c5d2638b99
|
@ -1148,6 +1148,8 @@ Servers should not trust client submitted content, and federated servers also sh
|
|||
|
||||
Servers should be careful to verify that new content is really posted by the actor that claims to be posting it, and that the actor has permission to update the resources it claims to. See also section 3. Objects Authentication and Authorization.
|
||||
|
||||
#### B.2.1 HTTP Signature
|
||||
|
||||
Verification of incoming posts SHOULD occur via a `http header signature` check. Currently, [draft 07 of the http signatures RFC](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-07) has become the *de facto* standard, although later versions MAY be implemented provided that sufficient support exists between federated servers.
|
||||
|
||||
A typical http signature created by Alyssa's server on an outgoing POST might look like the following:
|
||||
|
@ -1163,7 +1165,9 @@ http signatures SHOULD include `host`, `date` and a `digest` created from the po
|
|||
|
||||
The receiving server can obtain Alyssa's public key from `https://instancedomain/users/alyssa#main-key` and use it to verify the signature.
|
||||
|
||||
In addition, to allow for relaying of posts [linked data signatures](https://w3c-ccg.github.io/data-integrity-spec) MAY be used. This can allow posts to be verified as authentic even if they have passed through intermediate servers. An incoming post SHOULD be considered valid if its `http header signature` fails but an attached `linked data signature` passes.
|
||||
#### B.2.2 Linked Data Signature
|
||||
|
||||
To allow for relaying of posts [linked data signatures](https://w3c-ccg.github.io/data-integrity-spec) MAY be used. This can allow posts to be verified as authentic even if they have passed through intermediate servers. An incoming post SHOULD be considered valid if its `http header signature` fails but an attached `linked data signature` passes.
|
||||
|
||||
### B.3 Accessing localhost URIs
|
||||
It is often convenient while developing to test against a process running on localhost. However, permitting requests to localhost in a production client or server instance can be dangerous. Making requests to URIs on localhost which do not require authorization may unintentionally access or modify resources assumed to be protected to be usable by localhost-only.
|
||||
|
|
Loading…
Reference in New Issue