0.8 authentication before hooks - only ever getting a 401 Unauthorised

[mdskinner]

So I've figured out how to implement [email protected]
I like the new configuration file structure.

For anyone else looking, I guess the only thing you really need to implement to get 0.8 working is:

const token = authentication.TokenService;
const local = authentication.LocalService;

and

  app
    .configure(token())
    .configure(local())

I've chosen to do that in services/authentication

My question is two part, tho I'm sure fixing one will fix the other:

I'm finding the authentication before hooks aren't working. I'm only ever getting a 401 Unauthorised response with the standard hooks implemented. I've tried this on a clean install and by only using the feathers generator, they don't work by default.

I'm guessing If i can successfully auth.populateUser() I'd be able to interrogate the user afterwards - in my service or even elsewhere serverside?

Which leads to my last point. How do I actually get from the request token to iterating over the current logged in users properties.

I can see here that i should expect to find them in params.user (when the authentication hooks are set) which would be a beautiful thing.
#261 (comment)

Many thanks

[marshallswain]

@mdskinner Did you get things worked out ok, then?

[ekryski]

@mdskinner ya the current generator version is not compatible with [email protected]. Frindely reminder that you are running on the bleeding edge so things are likely to change a bit. However, thanks for trying it out! 😄

We are going to be moving to an entirely new CLI and generator very soon here that will be compatible.

[mdskinner]

Hey guys, @marshallswain @ekryski - Thanks.
Yep, I figured it out in the end.
Server-side Auth is working nicely and maintaining the user. All seems good.

I'm currently looking at the client-side Auth session now. It doesn't seem to hold/maintaining anything client side. Obviously I've got the token in cookie and in localStorage. But would you expect it to maintain an active session inline with the server-side session, ie, should feathers/client instantiate/pass-down the instance of feathers.user?
Or would you expect:
a) Auth to be handled entirely independently on both server and client
b) To have to re app.authenticate() on every hard refresh?

It seems like a shame to have to do an api call when bootstrapping the client-side routes just to see what the users permissions are.
Is there any way I should be able to expect app.user or at least even app.get('user') to be pre-populated ?
Am I missing something, or would you expect this?

Thanks again

[marshallswain]

@mdskinner we merged in three commits yesterday that are intended to move us in that direction. The rest adapter should now automatically pick up the SSR cookie. The realtime adapters still require you to call authenticate, but I think we should be able to get that worked out sometime. I just can't promise a timeframe because we have a major life event about to take place, but the little guy hasn't picked a birthday so far. 😉

[mdskinner]

@marshallswain Very exciting time, I completely understand.

After further investigation I'm finding consistently [email protected] client authenticates nicely and pulls back the user with type:token
However with 0.8.0 I'm finding:

  socket.io:socket emitting event ["authenticate",{"type":"token","token":"xxxValidTokenxxx"}] +0ms
  feathers-authentication:token Verifying token +1ms
  feathers-authentication:token Creating JWT using options: +4ms { algorithm: 'HS256',
  expiresIn: '1d',
  notBefore: undefined,
  audience: undefined,
  issuer: 'feathers',
  jwtid: undefined,
  subject: 'auth',
  noTimestamp: undefined,
  header: undefined }
  feathers-authentication:token Error signing JWT +1ms

If I switch back and forth between the two with the same setup (obviously changing out the config and the necessary .configure()'s)
0.7.9 works nicely, 0.8.0 doesn't. Is there something else I should be reckoning to change, or is it not at a point where client authentication is stable on your end either?

[marshallswain]

It was stable for me with those three commits I mentioned earlier, but if there have been more, I haven't tested with those.

[ekryski]

Just as any FYI @mdskinner 0.8.0 is an unstable alpha release right now. Some things might not be working as you expect and the API is still in flux. Hence why it isn't published. 😉

I'm not sure if you were aware of that and are trying to help get it solidified or if you are looking for help getting it to work. If it's the former, by all means help is very welcome! If it's the latter I would suggest sticking with 0.7.9 until 0.8.0 is published to npm.

We're using it in a couple projects right now to help solidify the API, but that also means that in some cases we are putting in some quick hacks to just "get shit working" so that we can figure out how best to clean it up.

[mdskinner]

@ekryski yer, no I absolutely do appreciate that and am aware of how these things work. It's essentially that I really like your framework and what it offers as far as a clean simple API layer with the services and hooks setup the way they are and think its the right fit for my project - which is a pretty big one. I'm making the clientside in React and the native app in React Native. There is no question there. But as of yet I'm struggling to find an API layer to centralise my data. All i really want is a strong authentication layer done for me and the pre and post CREATE manipulation like you have offered the rest I can create on my own. So its perfect really. But I'm not in the business of writing secure authentication layers and have no interest in doing so.
My problem lies in the fact that I can't get serverside working on 0.7.9 and i can't get clientside working on 0.8.0
I'm close to being forced to choose another API as I'm now throwing away valuable build time in attempting to debug authentication layers.
Do you have any idea why I might be unable to get serverside auth working with 0.7.9? I'm not wanting to have to make service calls on every single request. However I do need a populated user on every single request.

[ekryski]

@mdskinner so what is your main issue with v0.7.9? You don't have the user object coming back to the client after authentication? You should.

If you've configured the appropriate hooks on your services you should also have access to the user object in your hooks (via hook.params.user) on every request to a service, if you've added the appropriate hooks.

messageService.before({
  all: [
    authentication.hooks.verifyToken(),
    authentication.hooks.populateUser()
  ]
})

If you want to access the user object in middleware in v0.7.9 just copy some of the middleware from the 0.8.0 branch and register them before any custom routes and services. You can see the order they are registered right here. Hopefully that helps 😄

[mdskinner]

@ekryski I'm finding server-side auth not to be working on 0.7.9

process as follows:
new install: feathers generate
postman POST http://localhost:3030/users {jsonOBJECT}
confirm user in db, check

create simple form in public/index.html

        <form action="/auth/local" method="post">
          <input type="text" name="email"></input>
          <input type="password" name="password"></input>
          <input type="submit" value="go"></input>
        </form>

http://localhost:3030/auth/success

You are now logged in. We've stored your JWT in a cookie with the name "feathers-jwt" for you. It is: xxx

http://localhost:3030/users

401 - Not Authorized

Am I missing something?

[oscarhull]

@mdskinner Did you solve the issue, got the same behavior on my side?