user login does not work

pulkitsinghal commented 7 years ago

During login, an unexpected/strange query to the elasticsearch (ES) is made and it fails because ACL doesn't have any entries in ES and even though the result set should be empty, there isn't any _uid to sort on and that errors out in ES:

server:middleware:accessLogger DEBUG 127.0.0.1-X-X req +21s POST /api/UserModels/login

Elasticsearch DEBUG: 2016-11-01T18:30:28Z
  starting request { method: 'POST',
    path: '/test1/ACL/_search',
    body: { sort: [ '_uid' ], query: { bool: [Object] } },
    query: { size: 50 } }

Elasticsearch TRACE: 2016-11-01T18:30:28Z
  -> POST http://localhost:9200/test1/ACL/_search?size=50
  {
    "sort": [
      "_uid"
    ],
    "query": {
      "bool": {
        "must": [
          {
            "match": {
              "model": "UserModel"
            }
          }
        ],
        "should": [
          {
            "match": {
              "property": "login"
            }
          },
          {
            "match": {
              "property": "*"
            }
          },
          {
            "match": {
              "accessType": "EXECUTE"
            }
          },
          {
            "match": {
              "accessType": "*"
            }
          }
        ]
      }
    }
  }
  <- 400
  {
    "error": "SearchPhaseExecutionException[Failed to execute phase [query],
                   all shards failed;
                   ...
                   Parse Failure [No mapping found for [_uid] in order to sort on",
    "status": 400
  }

I ran this on mongodb connector and apparently this unexpected query exists there too:

server:middleware:accessLogger DEBUG 127.0.0.1-X-X req +16s POST /api/UserModels/login

loopback:connector:mongodb all +35ms ACL { where: 
   { model: 'UserModel',
     property: { inq: [Object] },
     accessType: { inq: [Object] } } }

loopback:connector:mongodb MongoDB: model=ACL command=find +1ms [ { model: 'UserModel',
    property: { '$in': [Object] },
    accessType: { '$in': [Object] } },
  [Function] ]

loopback:connector:mongodb all +5ms ACL { where: 
   { model: 'UserModel',
     property: { inq: [Object] },
     accessType: { inq: [Object] } },
  order: [ 'id' ] } null []

But mongo doesn't barf on it! It tolerates it and returns an empty result set.

Next Steps

I need to make ES more tolerant via the connector somehow
@raymondfeng or @bajtos - what is this no-op query all about? Why does it exist at all? Checking ACL for user model via connector for EXECUTE permissions on login method seems like a no-op to me, since ACL table/collection is never created, even in other connectors like mongo.

bajtos commented 7 years ago

@pulkitsinghal I think the query is triggered by the following line in loopback's common/models/acl.js: https://github.com/strongloop/loopback/blob/6d5d7f0d4a64f2a3938b5b53b7d35ae9271adf6f/common/models/acl.js#L355

AFAIK, LoopBack authentication requires you to attach ACL to a datasource, similarly to other auth models like Role and RoleMapping.

it fails because ACL doesn't have any entries in ES and even though the result set should be empty, there isn't any _uid to sort on and that errors out in ES:

I don't have enough knowledge about ES to help here. I would expect that automigrate/autoupdate should create an empty ACL table/connection in ES.

wolfgang-s commented 7 years ago

@pulkitsinghal Does this still happen with the new release? I think this could be because the access token is still not yet available for search ...

I got this error during my tests with 5.0 as well (_uid not sortable ...) I removed the defaulting sorting in here by removing the id:true on the model, then it works: https://github.com/strongloop-community/loopback-connector-elastic-search/pull/80/files#diff-2188140f8e1212974a697c3da77d751aL74

That's related I think.

loopbackio / loopback-connector-elastic-search

user login does not work #60

Next Steps