# Receiving 204 response but no cookie with the /api/security/v1/login endpoint

**URL:** <https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534>\
**Category:** Kibana\
**Created:** [February 7, 2019, 9:08pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534 "2019-02-07T21:08:01Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![an0nc0d3r](https://avatars.discourse-cdn.com/v4/letter/a/c4cdca/32.png) [@an0nc0d3r](https://discuss.elastic.co/u/an0nc0d3r)\
**Post date:** [February 7, 2019, 9:08pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/1 "2019-02-07T21:08:01Z")

</div>

When making a post request to `/api/security/v1/login` with valid credentials, I get a 204 (empty response), and no cookie 🍪 However, when I send invalid credentials, I get a 401 response.

**Request**  
POST /api/security/v1/login HTTP/1.1  
Host: DOMAN:5601  
kbn-version: 6.5.4  
Content-Type: application/json  
Cache-Control: no-cache  
{  
"password": "validPassword",  
"username": "validUsername"  
}

**Response**  
Status: 204 (No Content)

cache-control → no-cache  
connection → close  
date → Thu, 07 Feb 2019 19:45:47 GMT  
kbn-name → kibana  
kbn-xpack-sig → 3d56ded3222e4719c85f75a592fb4375  
vary → accept-encoding

If I send incorrect credentials (password or username), I get a 401 response, which is exactly what you'd expect. If Kibana is correctly recognising credentials, I can only assume that our environment is configured correctly?

**Request**  
POST /api/security/v1/login HTTP/1.1  
Host: DOMAN:5601  
kbn-version: 6.5.4  
Content-Type: application/json  
Cache-Control: no-cache  
{  
"password": "invalidPassword",  
"username": "invalidUsername"  
}

**Response**  
{  
"statusCode": 401,  
"error": "Unauthorized",  
"message": "[security\_exception] unable to authenticate user [invalidUsername] for REST request [/\_xpack/security/\_authenticate], with { header={ WWW-Authenticate="Basic realm=\"security\" charset=\"UTF-8\"" } } :: {"path":"/\_xpack/security/\_authenticate","query":{},"statusCode":401,"response":"{\"error\":{\"root\_cause\":[{\"type\":\"security\_exception\",\"reason\":\"unable to authenticate user [invalidUsername] for REST request [/\_xpack/security/\_authenticate]\",\"header\":{\"WWW-Authenticate\":\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\"}}],\"type\":\"security\_exception\",\"reason\":\"unable to authenticate user [invalidUsername] for REST request [/\_xpack/security/\_authenticate]\",\"header\":{\"WWW-Authenticate\":\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\"}},\"status\":401}","wwwAuthenticateDirective":"Basic realm=\"security\" charset=\"UTF-8\""}"  
}

**QUESTION**  
Do you have to configure the Kibana API in some way to respond with a cookie when using this endpoint? And if so... could someone please provide an example to achieve this?

Thanks in advance 👍🏻

Current approach is based off of this answer...

> [@Authenticating to iframe-embedded Kibana dashboard](https://discuss.elastic.co/t/authenticating-to-iframe-embedded-kibana-dashboard/71129/7):
>
> Sorry for the delay, @rupaln and sorry for giving incomplete advice. I was able to get the Kibana server to respond with a cookie header by POSTing to /api/security/v1/login with a JSON request body of { "password": "\<YOURPASSWORD\>", "username": "\<YOURUSERNAME\>" } and the appropriate kbn-version: 5.1.1 header.

**UPDATE ONE**

Have been digging around the Kibana src code and found the file that processed authentication requests to the endpoint mentioned above. Here'e the route that handles it... and I can't find any reference to a cookie being created and sent back. Am I missing something here?!

```
server.route({
    method: 'POST',
    path: '/api/security/v1/login',
    config: {
      auth: false,
      validate: {
        payload: {
          username: Joi.string().required(),
          password: Joi.string().required()
        }
      },
      response: {
        emptyStatusCode: 204,
      }
    },
    async handler(request, reply) {
      const { username, password } = request.payload;

      try {
        console.log('MY DEBUG', username, password)
        const authenticationResult = await server.plugins.security.authenticate(
          BasicCredentials.decorateRequest(request, username, password)
        );

        if (!authenticationResult.succeeded()) {
          return reply(Boom.unauthorized(authenticationResult.error));
        }

        console.log('AUTHENTICATION SUCCEEDED, WHERES MY DAMN COOKIE?!')

        const { authorization } = server.plugins.security;
        if (!authorization.mode.useRbacForRequest(request)) {
          const msg = `${username} relies on index privileges on the Kibana index. This is deprecated and will be removed in Kibana 7.0`;
          server.log(['warning', 'deprecated', 'security'], msg);
        }

        return reply.continue({ credentials: authenticationResult.user });
      } catch(err) {
        return reply(wrapError(err));
      }
    }
  });

```

---

<div class="post-metadata">

**Author:** ![Joe\_Fleming](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joe_fleming/32/3561_2.png) [@Joe\_Fleming](https://discuss.elastic.co/u/Joe_Fleming)\
**Post date:** [February 12, 2019, 5:39pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/2 "2019-02-12T17:39:38Z")

</div>

I haven't looked at the security code in a while, and it's changed a ton since I was last in there. I'm not sure why you get an empty 204 response with no header information... as far as I know we still use cookies to handle the session.

> Here'e the route that handles it... and I can't find any reference to a cookie being created and sent back. Am I missing something here?!

It's a bit tricky to follow how this works. Since our server uses [Hapi](https://hapijs.com/) (node framework), we use the routing hooks available there to deal with the auth part of handling the request. This uses a library called [hapi-auth-cookie](https://www.npmjs.com/package/hapi-auth-cookie), and the code that sets that up is [right here](https://github.com/elastic/kibana/blob/master/x-pack/plugins/security/server/lib/authentication/session.js#L112-L116).

I'll try digging into the route stuff a little and follow up with what I find.

---

<div class="post-metadata">

**Author:** ![Joe\_Fleming](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joe_fleming/32/3561_2.png) [@Joe\_Fleming](https://discuss.elastic.co/u/Joe_Fleming)\
**Post date:** [February 12, 2019, 6:31pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/3 "2019-02-12T18:31:27Z")

</div>

I just tried this locally, and it works as expected. The 204 response includes a `set-cookie` header that contains the session information. This happens both in the browser and also while using `curl`.

```auto
curl -XPOST -H "Content-Type: application/json" -H "kbn-xsrf: hello" localhost:5601/api/security/v1/login --data '{"username":"validUsername","password":"validPassword"}' -D -

```

That sends the header information to stdout, and you'll see the set-cookie parameter.

```auto
HTTP/1.1 204 No Content
kbn-name: kibana
kbn-xpack-sig: ce28f[..snip..]
vary: origin
cache-control: no-cache
set-cookie: sid=Fe26.2**b68af5[..snip..]; HttpOnly; Path=/
date: Tue, 12 Feb 2019 18:29:52 GMT
Connection: keep-alive

```

Maybe whatever tool you're using to set the request is hiding the `set-cookie` header from the response output?

---

<div class="post-metadata">

**Author:** ![an0nc0d3r](https://avatars.discourse-cdn.com/v4/letter/a/c4cdca/32.png) [@an0nc0d3r](https://discuss.elastic.co/u/an0nc0d3r)\
**Post date:** [February 12, 2019, 8:58pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/4 "2019-02-12T20:58:28Z")

</div>

Hi @Joe_Fleming

Thanks for getting back to me, I came back online to update the post because I _was_ getting the cookie, but PostMan was stripping the response headers out! Agghh! So you were right 🙂

However, I do now have a separate issue, now I have the cookie set on the client, I am getting the TOO\_MANY\_REDIRECTS error. I raised [this question](https://stackoverflow.com/questions/54618244/too-many-redirects-error-when-iframing-kibana-dashboard-using-cookies) on StackOverflow as I wasn't sure if I would get a response on Elastic forum... I need to be more patient 😉

Would you mind taking a look and let me know what you think? I can recreate the question as a Topic on here if you'd prefer though?

Thanks again

---

<div class="post-metadata">

**Author:** ![Joe\_Fleming](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joe_fleming/32/3561_2.png) [@Joe\_Fleming](https://discuss.elastic.co/u/Joe_Fleming)\
**Post date:** [February 13, 2019, 8:08pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/5 "2019-02-13T20:08:53Z")

</div>

Hrm, I'm not sure what's causing the redirect issue. For what it's worth, I was seeing something similar locally, just using Kibana. I would log in, Kibana would take me to the app I was trying to load, it would flash up briefly, redirect again, and then send me back to the login page. But I'm not familiar enough with how everything works to know what's causing that to happen without diving deep into the code to figure it out, and what I was seeing might be totally different from the issue you are seeing.

@Brandon_Kobel maybe you can shed a little light on what's causing the redirect here?

---

<div class="post-metadata">

**Author:** ![Brandon\_Kobel](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/brandon_kobel/32/14829_2.png) [@Brandon\_Kobel](https://discuss.elastic.co/u/Brandon_Kobel)\
**Post date:** [February 13, 2019, 9:20pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/6 "2019-02-13T21:20:55Z")

</div>

@an0nc0d3r the login endpoint isn't intended to be used in this manner, and it's definitely "unsupported". Generally, our lack of CORS support prevents this behavior, but you've overcoming it by your use of sub-domains. The cookie which Kibana replies with generally sets the httpOnly flag, and the secure flag (when hosted over https), in addition to the domain. If any of the settings differ for the cookie which you're trying to force Kibana to use, you'll see 2 cookies being submitted and behavior similar to what you're seeing.

---

<div class="post-metadata">

**Author:** ![an0nc0d3r](https://avatars.discourse-cdn.com/v4/letter/a/c4cdca/32.png) [@an0nc0d3r](https://discuss.elastic.co/u/an0nc0d3r)\
**Post date:** [February 13, 2019, 11:19pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/7 "2019-02-13T23:19:47Z")

</div>

@Brandon_Kobel... Got it one you absolute star! I was setting the Path to /, which mustn't of been set on the cookie coming out of Kibana.

As this approach is unsupported, though, can you suggest a supported way to achieve the desired goal?

Thanks again.

---

<div class="post-metadata">

**Author:** ![Brandon\_Kobel](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/brandon_kobel/32/14829_2.png) [@Brandon\_Kobel](https://discuss.elastic.co/u/Brandon_Kobel)\
**Post date:** [February 13, 2019, 11:32pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/8 "2019-02-13T23:32:43Z")

</div>

@an0nc0d3r if you're looking to do SSO, using SAML with an IdP is the best answer we currently have.

Would you mind elaborating on what you're trying to accomplish at a high level?

---

<div class="post-metadata">

**Author:** ![an0nc0d3r](https://avatars.discourse-cdn.com/v4/letter/a/c4cdca/32.png) [@an0nc0d3r](https://discuss.elastic.co/u/an0nc0d3r)\
**Post date:** [February 14, 2019, 12:14am UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/9 "2019-02-14T00:14:58Z")

</div>

@Brandon_Kobel My previous response was premature ☹

I think I had a fluke occurrence of it working as I am now seeing the same thing occurring after clearing cookies and refreshing the page.

I'm attempting to embed customer specific Kibana dashboards inside an iFrame in an Express application. Customers dashboards are created inside their individual spaces and have a user set up with appropriate permissions/role for viewing dashboards. Kibana is protected using X-Pack, requiring users to login.

This would require the user to log in twice, once to login into the application and again to access their Kibana dashboards, however, logging in just once to our application is the goal.

Looks like I'll be taking a closer look at SAML.

---

<div class="post-metadata">

**Author:** ![Brandon\_Kobel](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/brandon_kobel/32/14829_2.png) [@Brandon\_Kobel](https://discuss.elastic.co/u/Brandon_Kobel)\
**Post date:** [February 14, 2019, 12:31am UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/10 "2019-02-14T00:31:15Z")

</div>

@an0nc0d3r SAML should do exactly what you're looking for. The ES docs for getting started using SAML are really good: [https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-saml-realm.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-saml-realm.html)

The other option, which has it's limitations, is to use a reverse-proxy like NGINX to hard-code the credentials that are passed to Elasticsearch. This isn't great because anyone who can access the reverse proxy can automatically get access to Kibana, so it's really only good for providing the equivalent of "anonymous access".

There is one other option at the moment, and that's to use something like an OAuth2 proxy to do impersonation: [https://www.elastic.co/blog/user-impersonation-with-x-pack-integrating-third-party-auth-with-kibana](https://www.elastic.co/blog/user-impersonation-with-x-pack-integrating-third-party-auth-with-kibana)

We're working on additional auth providers for ES/Kibana, so if none of this satisfies your needs, please let me know and I can direct you towards our feature requests which helps us prioritize the addition of these providers.

---

<div class="post-metadata">

**Author:** ![an0nc0d3r](https://avatars.discourse-cdn.com/v4/letter/a/c4cdca/32.png) [@an0nc0d3r](https://discuss.elastic.co/u/an0nc0d3r)\
**Post date:** [February 14, 2019, 3:32pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/11 "2019-02-14T15:32:06Z")

</div>

Thanks the info @Brandon_Kobel.

I'll start making my way through the docs!

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [March 14, 2019, 3:32pm UTC](https://discuss.elastic.co/t/receiving-204-response-but-no-cookie-with-the-api-security-v1-login-endpoint/167534/12 "2019-03-14T15:32:14Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.