Update documentation around cookies

api/SPEC.md

@@ -54,7 +54,7 @@ that can be enabled (see
 [authentication](#reference/authentication)).
 
 Authentication is done with the login endpoint. The login endpoint
-returns an access token that is set as the `token` cookie.
+returns an access token that is set as the `X-Vault-Token` header.
 
 ## Help
 

api/client.go

@@ -105,12 +105,12 @@ func (c *Client) Token() string {
 }
 
 // SetToken sets the token directly. This won't perform any auth
-// verification, it simply sets the cookie properly for future requests.
+// verification, it simply sets the token properly for future requests.
 func (c *Client) SetToken(v string) {
 	c.token = v
 }
 
-// ClearToken deletes the token cookie if it is set or does nothing otherwise.
+// ClearToken deletes the token if it is set or does nothing otherwise.
 func (c *Client) ClearToken() {
 	c.token = ""
 }

api/client_test.go

@@ -81,7 +81,7 @@ func TestClientRedirect(t *testing.T) {
 		t.Fatalf("err: %s", err)
 	}
 
-	// Set the cookie manually
+	// Set the token manually
 	client.SetToken("foo")
 
 	// Do a raw "/" request

website/source/docs/auth/token.html.md

@@ -35,8 +35,8 @@ $ vault auth <token>
 
 #### Via the API
 
-The token is set directly as a cookie for the HTTP API. The name
-of the cookie should be "token" and the value should be the token.
+The token is set directly as a header for the HTTP API. The name
+of the header should be "X-Vault-Token" and the value should be the token.
 
 ## API
 

website/source/docs/http/index.html.md

@@ -35,8 +35,7 @@ depending on user settings.
 
 Once the Vault is unsealed, every other operation requires
 a _client token_. A user may have a client token explicitly.
-The client token must be sent as the `token` cookie or the
-`X-Vault-Token` HTTP header.
+The client token must be sent as the `X-Vault-Token` HTTP header.
 
 Otherwise, a client token can be retrieved via
 [authentication backends](/docs/auth/index.html).
@@ -46,10 +45,9 @@ login endpoints. These endpoints can be reached without any authentication,
 and are used for authentication itself. These endpoints are specific
 to each authentication backend.
 
-Login endpoints for authentication backends that generate an identity
-will be sent down with a `Set-Cookie` header as well as via JSON. If you have a
-well-behaved HTTP client, then authentication information will
-automatically be saved and sent to the Vault API.
+Login endpoints for authentication backends that generate an identity will be
+sent down via JSON. The resulting token should be saved on the client or passed
+via the `X-Vault-Token` header for future requests.
 
 ## Reading and Writing Secrets
 

website/source/docs/internals/architecture.html.md

@@ -55,7 +55,7 @@ clarify what is being discussed:
 * **Client Token** - A client token is a conceptually similar to a session cookie on a web site.
   Once a user authenticates, Vault returns a client token which is used for future requests.
   The token is used by Vault to verify the identity of the client and to enforce the applicable
-  ACL policies.
+  ACL policies. Unlike a cookie on a web site, this token is passed via HTTP headers.
 
 * **Secret** - A secret is the term for anything returned by Vault which contains confidential
   or cryptographic material. Not everything returned by Vault is a secret, for example