How to pass HTTP Basic Auth credentials within the URL?

Users Feedback
1

i’ve just started using this plugin.

i configure 2 groups and 2 users and managed to query data using command line :
curl -u user1:pw1 host1:9200/index1/_search

i didn’t figure how to use it from browser/url. i tried
http://user1:pw1@host1:9200/index1/_search

what is the right way to do this ?

2

Strange, what’s the browser?

3

hehehe, @sscarduzio as he said, the “browser” is curl:

curl -u user1:pw1 host1:9200/index1/_search

:smiley:

@sdba2 that curl should work… what is your config? also what is the result of the curl and what the elasticsearch logs say?

i’m betting that the config have some error, so we need to see the configs to find it! :slight_smile:

1 Like
4

hi,
thaks for answering and sorry for the delay, we’re having some holidays these days.

when i run the above curl (using user & pw) it works fine !
the problem is with the chrome (version 52) or with firefox (version 42)

5

hi,
here is my basic elasticsearch.yml file :

cluster.name: es52
node.name: node1
path.data: C:\elasticsearch\elasticsearch-5.2.0\data
path.logs: C:\elasticsearch\elasticsearch-5.2.0\logs
bootstrap.memory_lock: true
http.port: 9200

readonlyrest:
    enable: true
    response_if_req_forbidden: Forbidden by ReadonlyREST ES plugin
    
    access_control_rules:

    - name: Accept requests from users in group team1 on index1
      type: allow
      groups: ["team1"]
      indices: ["index1"]

    - name: Accept requests from users in group team2 on index2
      type: allow
      groups: ["team2"]
      indices: ["index2"]

    users:
    
    - username: user1
      auth_key: user1:pw1
      groups: ["team1"]
      
    - username: user2
      auth_key: user2:pw2
      groups: ["team2"]

The indexes
i’ve created 2 indexes and in each index one document.i used these commands:

PUT index1/type1/1
{
  "f1":"f1"
}

PUT index2/type2/1
{
  "f2":"f2"
}

TEST 1 (curl command line)

using the “curl” command line and it works as expectet :

$ curl localhost:9200/index1/_search?pretty
Forbidden by ReadonlyREST ES plugin

$ curl -u user1:pw1 localhost:9200/index1/_search?pretty
{
  "took" : 64,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "index1",
        "_type" : "type1",
        "_id" : "1",
        "_score" : 1.0,
        "_source" : {
          "f1" : "f1"
        }
      }
    ]
  }
}

$ curl -u user1:pw1 localhost:9200/index2/_search?pretty
Forbidden by ReadonlyREST ES plugin

$ curl -u user2:pw2 localhost:9200/index2/_search?pretty
{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "index2",
        "_type" : "type2",
        "_id" : "1",
        "_score" : 1.0,
        "_source" : {
          "f2" : "f2"
        }
      }
    ]
  }
}

TEST 2 (browser)
and i keep failing this test when using :
http://user1:pw1@localhost:9200/index1/_search?pretty
or
http://user2:pw2@localhost:9200/index2/_search?pretty

in test2 i use chrome 57

please advise.

6

Hi @sdba2, thanks for the clear report. Please see the below instructions.

How I test ReadonlyREST using the browser

  • Take an incognito window (important!)
  • Visit the URL without embedded credentials
  • The browser shows a native login form
  • Test using the wrong credentials, see it still shows a login form
  • Use the right credentials in the login prompt and see it working

This is done because HTTP Basic Auth has very loose specs and browsers tend to have different behaviours especially when the credentials are embedded in the URL.

Let us know if you have more luck with this other approach.

_Simone

7

hi, thanks for your response.

i’ve open a new chrome incognito window and enter : http://localhost:9200/index1/_search?pretty
and get the message “Forbidden by ReadonlyREST ES plugin” without getting any login form.

8

YES this is a bug. Just reproduced, thank you @sdba2. Fixing now :slight_smile:

9

Is this fixed? because I still don’t get the login prompt ?using 5.4.1

10

How it works now after fixes

If you want ROR to respond a generic 403 to unauthorized requests (that is no browser prompt)

    prompt_for_basic_auth: false

Instead if you want ROR to respond 401 with WWW-Authenticate: Basic response header (that is with browser prompt) :

omit the rule above, or set it to true.