verification e-mail can be bypassed via REST

[IBwWG]

If you use Postman to POST a valid (but not yet email-verified) set of email and password values to /auth/local with the header Accept: application/json, you get back a response that includes the verifyToken. Without the header you get an HTML response that says you've successfully logged in.

This is in dev mode (haven't tried the production windows patch yet) so hopefully this isn't here in production, as it allows someone to bypass the email verification step.

[eddyystop]

Could you provide the curl commands for these 2 cases? That would help a lot.

[IBwWG]

Sorry, I have to go, but here's what Postman would give me:

POST /users HTTP/1.1
Host: localhost:3030
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Postman-Token: 4d972208-4497-0e7d-8646-c4db82e7bced

name=i+have+a+name&username=nammmmmmmmmmme&password=what+the+hey&confirmPassword=what+the+hey&email=yes%40no.why

and then:

POST /auth/local HTTP/1.1
Host: localhost:3030
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Postman-Token: d78a579b-fd22-302e-a599-6843d6009483

email=yes%40no.why&password=what+the+hey

[IBwWG]

In my rush I didn't realize it was only one more click away. Oops. So, here are the curl commands (BTW, I just tested this in production too, and it also exposes the verifyToken):

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -H "Postman-Token: 95cf199c-f038-c893-7053-a8a09fbef2ca" -d 'name=i have a name&username=nammmmmmmmmmme&password=what the hey&confirmPassword=what the hey&email=yes@no.why' "http://localhost:3030/users"

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Accept: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: 018a022f-bf1b-7e4f-cf11-db40a5fce490" -d 'email=yes@no.why&password=what the hey' "http://localhost:3030/auth/local"

[eddyystop]

The HTTP REST request goes straight to feathers-authenticate. So it looks like its a problem with that rather than this repo.

I'm sorry but I think you have to take it there. You need to mention that its with v0.7.

[IBwWG]

OK will do. Thanks!

[IBwWG]

Er, wait. I would actually expect this behaviour (exposing a JWT and letting you log in) but only in the case that the user has already verified their e-mail. That feature is specific to this starter, so doesn't that make it an issue only applicable here?

[eddyystop]

"If you use Postman to POST a valid (but not yet email-verified) set of email and password values to /auth/local with the header Accept: application/json, you get back a verifyToken. Without the header you get an HTML response that says you've successfully logged in." The repo server uses only `app.configure(authentication);`. The repo client (which is not involved in this issue) is a websocket client using `feathers-reduxify-authentication` which uses `app.authenticate()` and `app.logout()`. So the repo doesn't directly handle the headers. The repo design uses a `isVerfied` flag which `feathers-authenticate` doesn't know about. The version of `feathers-service-verify-reset` brought into feathers core uses the same design. Since this seems to be an issue with headers, HTTP REST and perhaps `feathers-authenticate` design. So I think that's were the answer lies.

[IBwWG]

I don't think there's anything wrong with the headers per se: if I'm looking for JSON I get JSON back, and if not, I get HTML. That's great. The thing is, neither the JSON nor the HTML should report a successful login, since I've never verified my e-mail. I think I named this a bit poorly...I guess it doesn't matter about the JWT, it's more that it lets you log in without verifying your e-mail.