osmlab / ohauth Goto Github PK

Version 10.7.2 of tap just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As tap is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

If the query part of the URL contain parameters that were encoded as "application/x-www-form-urlencoded" string (i.e. something like "/something?query=spaced+words") then the stringQs function does not decode this plus signs as spaces (which it should according to section 3.4.1.3.1. of RFC 5849). The input string is only passed in decodeURIComponent. The current implementation looks like this:

ohauth.stringQs = function(str) {
    return str.split('&').filter(function (pair) {
        return pair !== '';
    }).reduce(function(obj, pair){
        var parts = pair.split('=');
        obj[decodeURIComponent(parts[0])] = (null === parts[1]) ?
            '' : decodeURIComponent(parts[1]);
        return obj;
    }, {});
};

This could be corrected by converting all '+' sign back to space before passing it in decodeURIComponent, like this:

ohauth.stringQs = function(str) {
    return str.split('&').filter(function (pair) {
        return pair !== '';
    }).reduce(function(obj, pair){
        var parts = pair.split('=');
        if(parts[1] === null) {
          obj[decodeURIComponent(parts[0])] = '';
        } else {
          obj[decodeURIComponent(parts[0])] = decodeURIComponent(parts[1].replace(/\+/g, ' '))
        }
        return obj;
    }, {});
};

After two hours of debugging I discovered that ohauth.js did an incorrect calculation of the HMAC key. Only afterwards I checked the closed issues and discovered pull request #6 and saw that this issue had already been fixed (note to self: always check the issues first!).

Knowing this I was a little baffled that I encountered this error an the first place (after all, it has been fixed two month ago). The reason for that was surprisingly stupid: I downloaded ohauth.js but the fix only applies to index.js!

To me, it looks like that ohauth.js is some kind of build output (since it includes the library uses for hashing). Could you please update the ohauth.js file to include this fixe from pull request #6 ?!

Is this still the standard way for iD's API to provide a login function?
Popups are no longer the way forward. In my tests, most browsers block them. Safari doesn't even give the user a notification. Popups have been abused unceremoniously.

Is there a way to change this to how the Tasking manager handles authorization?

It would be great if this library had typings to allow easy integration to angular and modern development tool that provide intellisense.
I have created a partial typings of what I needed as can be seen below.
Instruction of how to add this can be found here:
https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html
In short, you need to add a index.d.ts file and add a link in the package.json file to it.
Here's what I wrote - I'm sure it's pretty partial/incorrect:

export interface IOAuthResponse {
    oauth_token: string;
    oauth_token_secret: string;
}

export interface IOAuthParams {
    oauth_consumer_key: string;
    oauth_signature_method: string;
    oauth_timestamp: number;
    oauth_nonce: string;
    oauth_token: string;
    oauth_signature: string;
}

export interface IOhAuth {
    signature: (authSecret: string, tokenSecret: string, parameters: string) => string;
    baseString: (method: string, url: string, params: IOAuthParams) => string;
    /**
     * generates a querystring from an object
     */
    qsString: (obj: {}) => string;
    /**
    * generate an object from a querystring
    */
    stringQs: (str: string) => IOAuthResponse;
    timestamp: () => number;
    nonce: () => string;
    xhr: (method: string, url: string, params: {}, data: {}, options: {}, callback: (err, xhr) => void) => void;
}

Seems like repeated values should be represented, given the oauth spec

The API for ohauth.signature is as follows:

// generate a signature for an oauth request
ohauth.signature({
    oauth_consumer_key: '...',
    oauth_signature_method: '...',
    oauth_timestamp: '...',
    oauth_nonce: '...'
});

I call this method exactly as describe above, including the inline object initializer, and the consoles in both Chrome and Firefox report this:

Uncaught TypeError: Cannot read property 'length' of undefined 

Doing a bit of digging, I discovered that the oauth.signature() method requires three parameters: oauth_secret, token_secret, and baseString. These were not described at all in the documentation. The TypeError is being thrown because the utf8Encode() method is trying to encode the data parameter, given by rstr_hmac() from the d parameter, which was given by oauth.signature() from the baseString parameter.

I'm guessing that the signature method was intended to take in consumer secret, a retrieved OAuth token, and an already-compiled base string. The documentation should be updated to reflect that.

The last pull req included a 'little function' for this that should be a module instead.

I noticed that jsHashes is inside of ohauth.js but also listed as a dependency
Wondering - any reason for both?

It seems like the root cause of the Notes not working on osm.org after the Map controls redesign is ohauth not creating an absolute URL before computing the oauth signature.

@jfirebaugh found that switching from a relative to an absolute URL here made the posting work.