open-vault/vendor/github.com/joyent/triton-go/authentication/signer.go

//
// Copyright (c) 2018, Joyent, Inc. All rights reserved.
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
// file, You can obtain one at http://mozilla.org/MPL/2.0/.
//

package authentication

const authorizationHeaderFormat = `Signature keyId="%s",algorithm="%s",headers="%s",signature="%s"`

type Signer interface {
	DefaultAlgorithm() string
	KeyFingerprint() string
	Sign(dateHeader string, isManta bool) (string, error)
	SignRaw(toSign string) (string, string, error)
}
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is always written to a directory tree of the name and put in a `.vault_value` file. 2018-02-12 23:22:41 +00:00			`//`
			`// Copyright (c) 2018, Joyent, Inc. All rights reserved.`
			`//`
			`// This Source Code Form is subject to the terms of the Mozilla Public`
			`// License, v. 2.0. If a copy of the MPL was not distributed with this`
			`// file, You can obtain one at http://mozilla.org/MPL/2.0/.`
			`//`

			`package authentication`

			const authorizationHeaderFormat = `Signature keyId="%s",algorithm="%s",headers="%s",signature="%s"`

			`type Signer interface {`
			`DefaultAlgorithm() string`
			`KeyFingerprint() string`
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss 2018-07-06 16:09:34 +00:00			`Sign(dateHeader string, isManta bool) (string, error)`
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is always written to a directory tree of the name and put in a `.vault_value` file. 2018-02-12 23:22:41 +00:00			`SignRaw(toSign string) (string, string, error)`
			`}`