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

401 after service is moved/refactored #270

Closed
mdskinner opened this Issue Aug 15, 2016 · 9 comments

Comments

Projects
None yet
5 participants
@mdskinner
Copy link

mdskinner commented Aug 15, 2016

Ok so I've finally got to the root of my confusion here. There seems to be a very strange bug. Is there some sort of indexing or caching that is not exposed to the main part of the app?

Issue being: Generate a service and make an authenticated request parsing the jwt-token in the authorisation header. fine res 200 ok
However, it seems that if you rename/move that service the application can no-longer connect to it and thereafter will only ever get res 401

{
  "name": "NotAuthenticated",
  "message": "Authentication token missing.",
  "code": 401,
  "className": "not-authenticated",
  "errors": {}
}

Even tho the token is most definitely still being passed in the header and nothing else has essentially changed.
Are you able to reproduce this? Its cost me many many hours. Also a bit confusing/worrying if I am to want to re-factor services which is obviously very common, they seem to detach and become rendered void.
I know conceptionally this sounds absurd but i've been able to reproduce it many times now. Its definitely happening.

@daffl

This comment has been minimized.

Copy link
Member

daffl commented Aug 15, 2016

I am not sure what exactly you mean by renaming or moving a service. There is no caching, indexing or other magic happening. The verifyToken hook that seems to throw the error here just takes the token it got passed from the request header (Authorization by default if you didn't change it).

If it is related to authentication (e.g. the path of the user service) then you will have to update or set the endpoints in the authentication configuration accordingly.

More debug information on what's happening can be seen when setting the DEBUG=feathers-authentication* environment variable (also see http://docs.feathersjs.com/debugging/readme.html).

@mdskinner

This comment has been minimized.

Copy link
Author

mdskinner commented Aug 15, 2016

@daffl Yep, I've done all of the above thoroughly. It doesn't make any sense why its just not finding the Authorization header after refactoring a service. Anyway, good to confirm that there is no caching or magic of any sort.

@mdskinner mdskinner closed this Aug 15, 2016

@daffl

This comment has been minimized.

Copy link
Member

daffl commented Aug 15, 2016

If you can share the broken project and steps on how to reproduce the error we can definitely help to look into it.

@mdskinner

This comment has been minimized.

Copy link
Author

mdskinner commented Aug 16, 2016

@daffl You can see in this image the token is firmly assigned in the header:
screen shot 2016-08-17 at 2 09 37 am

Steps to reproduce are simply have a working service, any service it doesn't matter.

  • Re-name the service directory
  • Update the service require() constant & the app.configure() options in services/index.js to point to the new service module name.
  • Make the same http request that was working moments ago and it refuses to believe there is a token in the header. (when you can see quite clearly there is in the image, and nothing else has changed)

@mdskinner mdskinner reopened this Aug 16, 2016

@mdskinner

This comment has been minimized.

Copy link
Author

mdskinner commented Sep 1, 2016

@daffl
Any thoughts on this? Its still frequently happening.

@mdskinner

This comment has been minimized.

Copy link
Author

mdskinner commented Sep 2, 2016

@daffl
Ok, so I've finally happened to stumble across why this is happening. I guess in finding it - it now makes absolute sense, but Its a pretty important dependancy and easy to miss. The 'auth' service which is baked in along with all the other services MUST be configured first or else 'varifyToken' doesn't get passed the params.token in the header. Easy to miss in the current setup I'd say, would be good to call it out more clearly.

  // Auth service must run first
  app.configure(auth);

  // All other services
  app.configure(account);
  app.configure(fooService);

@marshallswain

This comment has been minimized.

Copy link
Member

marshallswain commented Sep 27, 2016

@mdskinner Thanks for being diligent. The next version of the plugin will make this a little more obvious,and we should definitely mention this in the docs.

@ekryski

This comment has been minimized.

Copy link
Member

ekryski commented Oct 26, 2016

Fixed in 0.8-beta and in the 1.0-alpha that is coming soon.

@ekryski ekryski closed this Oct 26, 2016

@letminin

This comment has been minimized.

Copy link

letminin commented Mar 15, 2017

I was facing exactly the same issue, we should check the order of configurated module and throw error in this case, waste about few hours on this 👍

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.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.