locked
WinJS.xhr and HttpClient work with Client Certificates, BackgroundDownloader doesn't

    Question

  • given this piece of code:

    getAsync = function(path) {
          return ensureCertficatesAsync().then(function() {
            var downloader, httpClient, url;
            url = config.baseUrl + path;
            logger.debug("GET", url);
            if (config.transer === "xhr") {
              return WinJS.xhr({
                url: url
              });
            } else if (config.transer === "background") {
              downloader = Windows.Networking.BackgroundTransfer.BackgroundDownloader();
              return Windows.Storage.ApplicationData.current.temporaryFolder.createFileAsync("d", Windows.Storage.CreationCollisionOption.generateUniqueName).then(function(file) {
                var download;
                download = downloader.createDownload(url.toUri(), file);
                return download.startAsync();
              }).then(function(download) {
                return Windows.Storage.FileIO.readAsync(download.resultFile);
              }).then(function(responseText) {
                return {
                  responseText: responseText
                };
              });
            } else if (config.transfer === "http") {
              httpClient = new Windows.Web.Http.HttpClient();
              return httpClient.getStringAsync(url.toUri()).then(function(responseText) {
                return {
                  responseText: responseText
                };
              });
            }
          });
        };

    I get correct responses with "xhr" and "http" mode. But the background downloader fails with a a "Security error".

    My server requires a client certificate. Everything is properly packaged in the app (and working with xhr and httpclient), the client cert is installed in the apps ROOT store and I have the servers cert deployed with the app (in the manifest).

    Does background API simply not support Client Certificates for any reason?

    Wednesday, June 4, 2014 10:01 PM

Answers

  • Yes that is correct Phil. The BackgroundDownloader class does not support Client Certificate authentication. If you have a specific scenario you are targeting, please let me know and I will forward it to the feature team.

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    • Marked as answer by pkursawe Friday, June 13, 2014 2:17 PM
    Wednesday, June 4, 2014 11:12 PM
    Moderator
  • Hi Phil,

    BackgroundDownloader does not use HttpClient directly, but uses the same WinINet API for the HTTP (or FTP) downloads and uploads. FTP does not support Uploads btw.

    As to why the BackgroundDownloader does not have support for client certificate is a good question :), but for the current release this appears to be by design. I have forwarded your scenario to the feature team to consider including the support for client certificates in the future.

    Also...the actual background transfer does not happen from your own process, it happens outside of your process and happens from within BackgroundTransferHost.exe from System32 directory.

    Thanks,

    Prashant


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    • Marked as answer by pkursawe Friday, June 13, 2014 10:03 PM
    Friday, June 13, 2014 4:45 PM
    Moderator

All replies

  • Yes that is correct Phil. The BackgroundDownloader class does not support Client Certificate authentication. If you have a specific scenario you are targeting, please let me know and I will forward it to the feature team.

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    • Marked as answer by pkursawe Friday, June 13, 2014 2:17 PM
    Wednesday, June 4, 2014 11:12 PM
    Moderator
  • Thanks for your swift response.

    Let me describe my scenario. I have an app that creates some data (files) that need to be uploaded to a server in the background. The app has an "uploads" folder that contains all the files to be uploaded. A file watcher registers changes in this folder and spawns a new upload for any file that is currently not already queued for upload/uploading. I am using HttpClient to do the upload at the moment (as I understand XHR is not supposed to be used for that kind of operation).

    Now I have to make all the queue management myself but more importantly once the app is in the background or terminated, no files will be uploaded. But this is crucial for the app. So at the moment I have a warning message that uploads are ongoing and the app should not be terminated by the user. But Windows can suspend/terminate it any time.

    Any idea how to solve that, now that Background API does not support client certs?

    Wednesday, June 4, 2014 11:49 PM
  •  Prashant could you ask the Product Team about why the background downloader is not capable of that? I assume it uses HttpClient internally so we could feed it client/server certificates through a new API method on the Upload/Download objects.

    Thanks!

    Friday, June 13, 2014 2:18 PM
  • Hi Phil,

    BackgroundDownloader does not use HttpClient directly, but uses the same WinINet API for the HTTP (or FTP) downloads and uploads. FTP does not support Uploads btw.

    As to why the BackgroundDownloader does not have support for client certificate is a good question :), but for the current release this appears to be by design. I have forwarded your scenario to the feature team to consider including the support for client certificates in the future.

    Also...the actual background transfer does not happen from your own process, it happens outside of your process and happens from within BackgroundTransferHost.exe from System32 directory.

    Thanks,

    Prashant


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    • Marked as answer by pkursawe Friday, June 13, 2014 10:03 PM
    Friday, June 13, 2014 4:45 PM
    Moderator
  • Thanks Prashant,

    I know its running in its own process, that's why I think it might be a little bit more complicated to put that in there. But they already have password authentication. So they need to save this information somewhere securely.

    Waiting for SDK updates. 

    For now I will just write my own desktop app for background transfers that I deploy alongside my LOB app.

    Friday, June 13, 2014 10:03 PM