Hello,

I am trying to use this consumer strategy along with local strategy.
If i am using it as stand alone strategy, everything is ok.
Due the fact that this npm package is using an outdated version of passport, i am not able to use it.
At this moment i've updated version in package.json and is working as expected.
Please update the package.json version for passport.

First of all thanks for the library. It`s very easy to implement 'oauth' server provider side with it.

Recently I had a task of creating several routes with the same beginning part of the url. For instance, the start of all urls is '/base' and every route under the base must be checked with 'oauth' (ConsumerStrategy from the library) passport authentication middleware, like the following:

app.use('/base', passport.authenticate('oauth', {session: false}), require('./oauth-api'));

in the 'oauth-api' file I create a Route and add 8 urls. So, the complete routes look like this:

router.get('/route1', controller.route1); router.get('/routeN', controller.routeN);
When an oauth Consumer prepares a request to my server, it creates oauth_signature. The URL part of the signature would be like the following:

http://localhost:{port}/base/route1

Whereas the library would consider the url without the base, like this:

http://localhost:{port}/route1

And therefore the signatures don`t match.

The solution that worked for me was to amend ,mentioned in the topic, the 'originalURL' the line

path = req.url || '';

to the line

path = req.originalUrl || '';

Let's say you create an app with a router (free typing follows)

route = express.Router();
route.get('/profile',   
    passport.authenticate('token', {
            session: false
     }), _get_profile);

app = express();
app.use("/api/1.0", route);

when helpers.originalURL is called, it will come up with /profile/ which then will be fed into the HMAC-SHA1 algorithm for the base (at around line 206 of token.js)

Unfortunately, the client has computed the base using /api/1.0/profile and so the signatures don't match.

First off, thank you for the great work. Have learned a lot about oauth while using your modules.

I have a scenario where we want to use 2-legged oauth (I'm aware that the definition of 2-legged oauth may vary and sometimes this scenario is called 0-legged, but anyway...).

Using passport-http-oauth, I'm able to implement a 2-legged scenario where the access_token isn't needed. The problem is that most descriptions on 2-legged scenarios want to send an empty access_token. In your module, you check if the access_token string is empty, and if it is, you throw an error (parameter_missing).

So, my question is, would it be safe and useful to have an option to omit the check for an empy access_token. I can write the code, but wonder if you would find it useful in you repo.

Thanks

The utils.plaintext function uses the utils.encode function to encode the plain text signature. This causes the this causes the plain text signature received from the request to be found invalid as the it is never encoded after having been parsed from the request (the utils.parseHeader function decodes all values).

https://github.com/jaredhanson/passport-http-oauth/blob/master/lib/passport-http-oauth/strategies/utils.js#L25

In particular, in koa, req.connection.encrypted defaults to 'keep-alive'

Just wondered whether I could use the 'token' strategy to validate simple GET requests in the form of http://my.api.com/<API_KEY>/<TOKEN>/resource?

RFC 5849 §3.4.1.3.1 mandates that if the HTTP request contains a single valid application/x-www-form-urlencoded entity-body, its contents be parsed into key/value pairs and added to the list of parameter sources that are covered by the OAuth 1 signature.

Currently, passport-http-oauth checks whether the Content-Type is application/x-www-form-urlencoded and uses req.body if it is. This requires a separate middleware to be present in the chain to decode the entity-body to req.body. Furthermore, this requires said middleware to decode it to a simple list of key/value pairs to follow the spec. Unfortunately, the common body-parser middleware urlencoded() does not do this.

Consider:

POST /test HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

foo=bar&foo=baz

const express = require('express')
const passport = require('passport')
const {ConsumerStrategy, TokenStrategy} = require('passport-http-oauth')

passport.use('consumer', new ConsumerStrategy(
	(consumerKey, done) => done(null, {}, 'secret'),
	(requestToken, done) => done(null, false),
))

const app = express()
app.post('/test',
	express.urlencoded({extended: true/false}),
	passport.authenticate('consumer', { session: false }),
	(req, res) => res.json('ok'))

As documented in the Node.js docs, querystring.parse, which is called if {extended: false}, parses this request body as:

req.body = {'foo': ['bar', 'baz']}

As a result, passport-http-oauth attempts to sign the string ...%26foo%3Dbar%252Cbaz instead of the expected ...%26foo%3Dbar%26foo%3Dbaz, and authentication fails when it should succeed (and succeeds when it should fail, if the client does the same!).

qs.parse, which is called if {extended: true}, doesn’t explicitly document this in the README, but as far as I can tell from the source code, it does the same and this cannot be disabled. Furthermore, it also parses several special syntaxes for complex objects and arrays.