Body-parser conflicts if configured outside this library

[robertjd]

The login handler accepts JSON and form-encoded posts. We use the body-parser module to parse these. When a social login is performed the posted object has nested properties:

{
  providerdData: {
    providerId: '',
    code: ''
  }
}

To read these types of bodies, we use the extended: true option of the body-parser library.

However, if the developer has configured the body-parser library outside of our library like this (meaning that this middleware function is place before our router):

app.use(bodyParser.urlencoded({ extended: false }));

The body will be parsed without the extended fields, and our login handler will fail and return "invalid username or password". This is a nuance of the body-parser library, as it won't re-parse a body if it's already done so:

https://github.com/expressjs/body-parser/blob/master/lib/types/urlencoded.js#L80

The workaround is to tell the developer to ensure that the option is set to true. But it would be nice to find a body parsing solution that isn't affected by edge cases that arise from configuration that is outside of this library

[baer]

I've been looking through the code and it looks like you only use body-parser in your controllers and don't actually need to register it for the external app! Since you have full access to these I believe you can use body or raw-body (both recommended by the folks who maintain body-parser). If you did that, you could remove the dep on body-parser altogether which would close both this and #180.

[timothyej]

Seems like this problem still exist, using the body parser, my login request gets stuck in pending.

[robertjd]

@timothyej can you elaborate on how you're seeing this problem? If you could show or link to sample code that would be great.

[timothyej]

All I did was to add this line before adding the Stormpath middleware:

app.use(bodyParser.urlencoded({ extended: false }));