TypeError: Cannot read property 'headers' of undefined at getPaginated

[rohan-deshpande]

Error is occurring at RequestHelper.js:116:44 when attempting the following

const gitlab = new GitLab({ url, token });

describe('projects', () => {
  it('should fetch projects as an array', done => {
    gitlab
      .Projects
      .all()
      .then(projects => {
        console.log(projects);
        done();
      })
      .catch(console.log);
  });
});

Note that I can access the projects via postman with

{{gitlab}}/api/v4/projects?private_token={{token}}

[jdalrymple]

hmm, ill look!

[jdalrymple]

What version of the package are you using? And do you have problems running any of the other functions?

[rohan-deshpande]

Ah sorry, 3.7.0, nothing really seems to work, I keep getting this error

[jdalrymple]

Hmm thats really odd... Looking!

[jdalrymple]

Could you check if you get the same problem in an earlier version of the package?

[rohan-deshpande]

Can do, let's just make sure this is not a user error first though, are you expecting the url prop passed to the constructor to contain the /api/v4 suffix or are you appending it? I wasn't really clear about this.

Edit: same issue in 3.6.0 this makes me think that it's something I'm doing incorrectly...

[jdalrymple]

I append it internally, the url just need to be the base url, like: https://gitlab.com

[rohan-deshpande]

Heh, okay, it's a certificate issue. I'm behind a proxy. Logging the err inside that method yields

name: 'RequestError',
  message: 'Error: unable to get local issuer certificate',
  cause:
   { Error: unable to get local issuer certificate
       at TLSSocket.<anonymous> (_tls_wrap.js:1098:38)
       at emitNone (events.js:105:13)
       at TLSSocket.emit (events.js:207:7)
       at TLSSocket._finishInit (_tls_wrap.js:628:8)
       at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:458:38) code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY' },

Basically.

[jdalrymple]

😂 woo, glad we figured it out

[rohan-deshpande]

Hmm wonder how I can get around it... bit weird that it doesn't happen when hitting the API directly

[jdalrymple]

hmm, could it be an issue with the Request module? Can you access the API directly through the Request module ?

[rohan-deshpande]

Do you mean the RequestHelper class?

[jdalrymple]

Nope, i mean with the Request Library: https://www.npmjs.com/package/request

[rohan-deshpande]

Ah right so you're using this to perform the requests, let me try.

[jdalrymple]

yup! It will help narrow down where the error is coming from

[rohan-deshpande]

Okay yeah, happens there too. I can get around it by passing an option to the call like

const rejectUnauthorized = false;

request({ url, rejectUnauthorized });

Are all options passed to the constructor passed down to the request call? If so then passing this as an option should just work.

[jdalrymple]

No the options are not passed down :( If there another way around that problem?

[rohan-deshpande]

I don't think so. It's a legit use case imo because in some corporate environments, non standard certs are used or certificates are not managed by the developers themselves making it hard to have any kind of control over them.

Given that GitLab focuses on self-hosting, I think this would be a good option to include. Let me know if you think so and I'll see if I can get a PR done.

[jdalrymple]

Hmm, i agree. How does this flag work with other request modules? For example we use the XMLHttpRequest module as well in this library ? (Eventually to be refactored out to support any request module the user would like #98

[rohan-deshpande]

Any reason why you are using two libraries? Why not just use one?

[jdalrymple]

I started with the Request module because it was one of the most used/well tested request modules i could find. The XML request module was added after to support xhr request for the browser. A better library to upgrade to may be cross-fetch, which handles all of these cases. Before switching the main request library around, id like to do more research to at least try and maintain the same API if possible instead of having to update everything

[rohan-deshpande]

Ah okay makes sense. I think node-fetch might be the best option then because the implementation is identical to the browser spec.

[jdalrymple]

Meh, this library was build specifically for node, so whether it maintains adherence to the browser spec is less important. As long as it is consistent s'all good. Another one another contributor suggested was axios?

[rohan-deshpande]

I wouldn't use Axios personally. Fetch is the way forward.

Get what you're saying about it being node specific, but supporting browsers is also nice because it means people can use your lib to create some cool UIs.

[MartinBenninger]

I think this is actually an issue with the node-gitlab library and not just the request package.

We use this library in the browser with the XMLHttpRequester and we get the same error whenever a request fails.

TypeError: Cannot read property 'headers' of undefined

This happens for example when making a request to a repository that the user does not have access to. Previously the real HTTP error was passed to the error function.

I think that it's coming from the bit of code that tries to get the sleep time from the 'retry-after' header.

const sleepTime = parseInt(err.response.headers['retry-after'], 10);

Let me know if you need any more information. I can also try to make a small sample to reproduce the error.

[jdalrymple]

Hmm, alright I'll look into it tonight

…

On Aug 9, 2018, 11:49 AM, at 11:49 AM, Martin Benninger ***@***.***> wrote: I think this is actually an issue with the node-gitlab library and not just the request package. We use this library in the browser with the XMLHttpRequester and we get the same error whenever a request fails. `TypeError: Cannot read property 'headers' of undefined` This happens for example when making a request to a repository that the user does not have access to. Previously the real HTTP error was passed to the error function. I think that it's coming from the bit of code that tries to get the sleep time from the 'retry-after' header. `const sleepTime = parseInt(err.response.headers['retry-after'], 10);` Let me know if you need any more information. I can also try to make a small sample to reproduce the error. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #142 (comment)

[jetersen]

@rohan-deshpande and @MartinBenninger even still you should be able to include the extra certs into NodeJS this is how it should be solved you don't want to start down the dark path of ignore certs.

Added this to our package.json and the pem includes all our internal certs 😄 Has been working great for us.

"scripts": {
    "start": "NODE_EXTRA_CA_CERTS=./secrets/3ShapeCA.pem node bot.js"
},

https://nodejs.org/api/cli.html#cli_node_extra_ca_certs_file

[jdalrymple]

There are two problems in this issue lol 1. Certificates but @Casz has pointed out how to handle that, and 2. The sleep propagating header not found errors. This second one im working on now!

[jdalrymple]

Pushed up a fix for the headers

[rohan-deshpande]

I don’t think the suggested solution works if your certificates are borked. Which mine are, and I have no control over them. It’s not a viable solution for everyone where as passing the request option is.

I’ve fallen back to just hitting the API directly with request for now and it’s all working fine.

[jdalrymple]

Hmm, I guess so eh. I'll add the extra param then to the init logic.

[jetersen]

@rohan-deshpande you really ought to handle certs in the way that I suggested above. This other way is just an excuse.
All you have to do is take your company's public root CA, you can grab this one through Chrome, no need to contact your IT department and put it into the pem file.

If you want to include more you simply add them all into one pem file, there is really no excuse to not doing it.

Save it as DER x509

Convert x509 to PEM

You can also run: openssl s_client -connect HOST:PORT -showcerts to get the certificate chain and in there you should be able to find the public root CA PEM format in your chain

[rohan-deshpande]

Of course I’ve already tried this. The certs are not actually valid. That’s the problem. I don’t think it’s helpful to assume that everything is as it should be in the myriad of corporate mess that others have to deal with.

[jdalrymple]

Although i agree with @Casz , I see your point. If the user of the library is ok with ignoring certs that's their business.

[rohan-deshpande]

I agree 100% in principle as well. It’s just that these things aren’t always as they should be.

[jdalrymple]

🎉 This issue has been resolved in version 3.10.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[rohan-deshpande]

Nice one, thanks.