body-parser needs to be a dependency.

[vangorra]

Adding body-parser as a dependency and configuring it. Also untracking .npm directory, which really shouldn't be tracked.

[rodrigok]

@vangorra what happens if already there is one body parser before?

[vangorra]

An error saying cannot read property token of undefined.

[rodrigok]

So, maybe you should check if a body parser exists or turn this optional, right?

[vangorra]

Optional, no. The README for node-oauth2-server demonstrates that the npm body-parser package is required. The existing source for this package doesn't include it.

[rodrigok]

If some user is trying to put this package as a middleware that already have the body parser implemented he will have 2 body parsers trying to parse the same body.

The question is, if we have 2 body parsers trying to decode an url encoded body what will happen?

[vangorra]

In this case, it doesn't looks like it will matter considering the body parser is being attached to the "app" which is a new instance of express. So the body parsing would be isolated to the routing the "app" variable handles.

[rodrigok]

Yes, but think about something like:

var bodyParser = Npm.require('body-parser');

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

Will decode the body 2 times.

I'm saying that because you can attach this package to another libraries like JsonRoutes.Middleware.use(oauth2server.app)

[vangorra]

Hmm.. I see your concern.

Time to re-evaluate the problem:
The whole issue is caused by oauthserver.coffee initializing routes for get/post on the /authorize url. This approach stuck me as a bit odd for meteor anyway. Meteor does behave like traditional webservers where the page is rendered and sent to the browser. Instead, it distributes the code necessary to render the site and meteor handles two-way data communication with the server. So the concept of having a post-back url handler (@app.post '/oauth/authorize' ...) on a meteor server to handle user data entry is odd.
A more meteor-like solutions would be to remove the authorize url configurations and handle the authorization of client access with a meteor method. The trouble with this approach is the oauth2server (npm module) relies heavily on manipulating an express object for redirects and such. This would be worked around by giving the module mocked object or rolling a fork of the module.

[rodrigok]

The node-oauth2-server https://github.com/thomseddon/node-oauth2-server/pull/203?ts=2 project is being refactored to remove the express dependency, so we can improve that in the future, now this solve our main problems.

[engelgabriel]

@rodrigok and @vangorra the refactor has been merged! :)

Time to re-evaluate the problem again?

[sampaiodiego]

wow, this is old!

do you guys have something new to say? or may I close this?

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}