Support for object based url

[nickbeckenham]

Is it possible to add support for an object based url in the manifestUrl and packages.*.url fields? This would allow custom options to be passed in to the request module for get/download calls.

I ask because in my development environment for SSL I use a self signed certificate and by default the request module will reject the certificate.

I tried passing in the object so it would be something like:

packages : {
  win : {
    url: {
      url: 'https://localhost/update.zip',
      strictSSL: false
    }
  }
}

This works nicely (esp for checkNewVersion), however it then fails when choosing the temp path to save to because it converts the 'url' to '[object Object]'.

[adam-lynch]

@edjafarov thoughts?

[edjafarov]

@solgarius can you create a PR? I am not sure what are you proposing. I will dig it though with your help it would be faster.

[nickbeckenham]

@edjafarov

I'm happy to create the PR but first I'd like your clarification on which approach you would prefer. I can think of 3 ways to do this, none of which are particularly wrong, just depends on your feelings about how the options work.

1> Extract the url from inside the object to get the temp file name packages.*.url can be Object or String. If object then we get the url by looking for url['url'] or url['uri'] as per the request npm api. Sample settings:

manifestUrl : {
  url: 'https://localhost/package.json',
  strictSSL: false
},
packages : {
  win : {
    url: {
      url: 'https://localhost/update.zip',
      strictSSL: false
    }
  }
}

2> Supply the url and the request options separately. So you would keep the url as a string and have an additional 'requestOptions' e.g.

manifestUrl : 'https://localhost/package.json',
packages : {
  win : {
    url: 'https://localhost/update.zip'
  }
},
requestOptions: {
  strictSSL: false
}

3> Allow url to be an object and have a separate 'tempFileName' option. e.g.

manifestUrl : {
  url: 'https://localhost/package.json',
  strictSSL: false
},
packages : {
  win : {
    url: {
      url: 'https://localhost/update.zip',
      strictSSL: false
    },
    tempFileName: 'update.zip'
  }
}

I'm happy to do any of these approaches or a combination of them if you would like. My preference is probably for 2 or 3 because it means we don't have to worry if the npm request module changes its api.

[edjafarov]

Oh, seems I got it. So would it work for you if updater.prototype.checkNewVersion https://github.com/edjafarov/node-webkit-updater/blob/master/app/updater.js#L38

and updater.prototype.download https://github.com/edjafarov/node-webkit-updater/blob/master/app/updater.js#L71

will have optional args that would allow to modify options for mikeal's request?

[nickbeckenham]

That sounds like it would work.