Express Middleware local -> jwt does not authorize on redirect

[snewell92]

Steps to reproduce

Run the following:

$ mkdir new-test-app
$ cd new-test-app
$ feathers generate app .
  (src | yarn | REST, SocketIO)
$ feathers generate connection
  (choose neDB)
$ feathers generate service
  (users | neDB)
$ feathers generate authentication
$ yarn install
$ yarn add ejs
$ mkdir views
$ touch views/failure.ejs views/home.ejs src/routes.js
$ yarn install
$ npm start

In POSTMAN create a new user by executing a POST request to localhost:3030.
Then authenticate with those new credentials to get an access token back.

Kill feathers app.

Follow this gist to update public/index.html (replace what's in there now), views/failure.ejs, views/home.ejs, src/routes.js as per the docs, and src/app.js

Now npm start again to launch the app. This time POSTMAN will still work, and be able to fetch the home view if the Authorization header is set. However when you navigate to / in chrome and submit the login form with the same creds, feathers returns a 401 - this is where I'm stuck.

Expected behavior

User should be redirected to /home as an authenticated user via the express route middleware.

Actual behavior

User received 401.

System configuration

Module versions:
feathers-authentication@1.2.3
NodeJS version:
v7.10.0
Operating System:
Win 10 64-bit
Browser Version:
Chrome v58

Further explanation

auth.express.authenticate('jwt') doesn't seem to cooperate with a login POST route that uses auth.express.authenticate('local'). I have mentioned this before on #495 and #469; these related issues either experienced a different symptom or are about something very specific, and thus I think this issue is a more general once.

Also, when I purposefully give the wrong credentials the user gets sent to the /fail route and failure.ejs is rendered, all good, but then this error is shown in the console:

Request for '/fail'...
Error: Can't set headers after they are sent.
    at ServerResponse.setHeader (_http_outgoing.js:371:11)
    at ServerResponse.header (...\response.js:730:10)
    at Object.formatter.text/html (...\error-handler.js:48:13)
    at ...\error-handler.js:83:36
    at Layer.handle_error (...\layer.js:71:5)
    at trim_prefix (...\index.js:315:13)
    at ...\index.js:284:7
    at Function.process_params (...\index.js:335:12)
    at next (...\index.js:275:10)
    at ...\not-found-handler.js:9:5

Thank you very reading <3<3

---

I just tried adding cookie config in my default.json and with/without cookie-parser with no luck.

[snewell92]

This may well still be an issue, but I think I'm going to simply work around it. As I stop to think about it further, I don't think I want the jwt to be passed to the user for the user to send back. That seems vulnerable. If someone else comes runs into this feel free to disagree and I can reopen, but the next step in my scheme is to have subsequent browser navigation remember the user. This is the responsibility of the server to store the JWT in memory, associated with the user id. Then a custom service to look like up and then pass the the jwt to the authentication service. I want to move away from storing session cookie/session tokens. I ended up using sessions to store the jwt. Because that's essentially what I needed as described in more detail here. Using secure cookies and having express-session manage the session provides enough security.