Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Unauthorized" Response with Hook Data #291

Closed
cvalarida opened this Issue Sep 14, 2016 · 6 comments

Comments

Projects
None yet
2 participants
@cvalarida
Copy link

cvalarida commented Sep 14, 2016

Bad title, I know. Sorry.

The story goes like this:
I'm implementing authentication on an app that I'm migrating from Laravel. Previously, I did everything manually, so I knew exactly what was going on. Now that I'm using Feathers JS and the feathers-authentication package, there's some magic involved and I don't know what's up now.

After creating the Feathers app via the feathers generator, I tweaked the endpoints of my api calls to prepend them with /api--that's the only thing I've done different from the default as far as I can recall. That said, here's the code:

Client

///////////////////
// Initial setup //
///////////////////
const app = feathers()
  .configure(hooks())
  .configure(socketio(socket))
  .configure(authentication({ storage: window.localStorage }));

// Attach it to window for global use
window.app = app;



// Later on, when I try to log in...
window.app.authenticate({
    type: 'local',
    email: username,
    password: password
}).then(function (response) {
    console.log("Success:", response);
}).catch(function (error) {
    console.log('Failure:', error);
});

Server

Authentication service...

//////////////////////////////
// Configure authentication //
//////////////////////////////
let config = app.get('auth');
app.configure(authentication(config));

The config in question:

{
  "auth": {
    "idField": "id",
    "token": {
      "secret": "redacted"
    },
    "local": {
      "userEndpoint": "/api/users"
    }
  }
}

The Problem

When I send in my authentication request with the wrong password, I get the following response (from examining the websocket):

[
  "unauthorized",
  {
    "name": "NotAuthenticated",
    "message": "Invalid login.",
    "code": 401,
    "className": "not-authenticated",
    "errors": {}
  }
]

Looks good, right? Okay, so now let's log in with the proper password...

[
  "unauthorized",
  {
    "hook": {
      "data": {
        "id": 102,
        "accountId": 1,
        "email": "email@mail.com",
        "password": "redacted",
        "api_token": null,
        "permissions": null,
        "deletedAt": null,
        "createdAt": "2016-09-01T00:41:54.725Z",
        "updatedAt": "2016-09-14T17:14:00.401Z"
      },
      "params": {
        "data": {
          "id": 102,
          "accountId": 1,
          "email": "email@mail.com",
          "password": "redacted",
          "api_token": null,
          "permissions": null,
          "deletedAt": null,
          "createdAt": "2016-09-01T00:41:54.725Z",
          "updatedAt": "2016-09-14T17:14:00.401Z"
        }
      },
      "method": "create",
      "type": "after",
      "result": {
        "id": 102,
        "token": "redacted"
      }
    }
  }
]

Er...What? Checking my console also shows me Failure: Object {hook: Object} so it's clearly running the .catch(), but...why??

I'm stuck...Any ideas? Am I doing something wrong? Is it a bug? I'm using feathers-authentication@0.7.9.

@daffl

This comment has been minimized.

Copy link
Member

daffl commented Sep 15, 2016

Can you POST with email and password to the auth/local route with e.g. Postman?

@cvalarida

This comment has been minimized.

Copy link
Author

cvalarida commented Sep 16, 2016

I don't think I have REST enabled server-side, so no. I get:

{
  "name": "GeneralError",
  "message": "Cannot read property 'get' of undefined",
  "code": 500,
  "className": "general-error",
  "data": {},
  "errors": {}
}

when POSTing

{ "type": "local", "email": "email@mail.com", "password": "newPass" }

In other news, I made a repo to demonstrate this issue at https://github.com/cvalarida/feathers-auth-bug

If it's a bit of a pain to set up, sorry--dev ops isn't really my thing. It should be fairly straightforward, though. I've got all the setup instructions in the README.

Thanks.

@cvalarida

This comment has been minimized.

Copy link
Author

cvalarida commented Sep 19, 2016

Hmm, I do have REST configured in the aforementioned repo, and it still results in the same error when POSTing to /auth/local. It's a proper error (invalid login) when the email or password is wrong, but when they're correct, they give that GeneralError above.

Looking at my server terminal, I get a little more information, but I don't know what to do with it yet. It flagged the following error:

info: TypeError: Cannot read property 'get' of undefined
    at /vagrant/node_modules/feathers-authentication/lib/hooks/populate-user.js:30:45
    at Object.<anonymous> (/vagrant/node_modules/feathers-authentication/lib/hooks/populate-user.js:29:12)
    at process._tickCallback (internal/process/next_tick.js:103:7)
@cvalarida

This comment has been minimized.

Copy link
Author

cvalarida commented Sep 19, 2016

Hey! There it is. Finally got it. So dumb... It was a matter of config.

Previously, I had:

{
  "auth": {
    "idField": "id",
    "token": {
      "secret": "redacted"
    },
    "local": {
      "userEndpoint": "/api/users"
    }
  }
}

But what I really needed was:

{
  "auth": {
    "idField": "id",
    "token": {
      "secret": "redacted"
    },
    "userEndpoint": "/api/users",
    "local": {}
  }
}

So when I called it via REST, it had nothing to get from, since it didn't actually get a user back (had the wrong userEndpoint; it was only defined in local). Makes much more sense now on that front.

What I don't understand, though, is why it returned an error and the hook data previously (when using the websocket).

@cvalarida cvalarida closed this Sep 19, 2016

@daffl

This comment has been minimized.

Copy link
Member

daffl commented Sep 19, 2016

Glad you figured it out! We'll make sure this is more obvious when we release the next version and update the documentation,

@cvalarida

This comment has been minimized.

Copy link
Author

cvalarida commented Sep 20, 2016

Yeah, after I figured it out, I found the example in the documentation, so I felt pretty brilliant. The only thing I can think of to make it more clear is mentioning using the userEndpoint outside of a specific auth provider configuration, otherwise funky stuff happens. Other than that, my problem was just skimming the documentation and putting it in the wrong place despite the example.

Thanks for pointing me in the right direction!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.