How does msixauth work? about msix-packaging HOT 18 OPEN

I'm able to reproduce this issue on my computer. My gut feeling is that it is a bug on the App Installer at the intersection of installing .appinstaller files and using msixauth, where we don't use the auth we got for accessing the .appinstaller file to also access the package. I still need to do some debugging to confirm it, though.

from msix-packaging.

I'm not sure I'm understanding what you are trying to accomplish. Are you trying to get Visual Studio to publish you MSIX package or .appinstaller file to a location that requires authentication?

What you linked would not be able to do that. The msixauth parameter only helps for fetching files to install when you are using the ms-appinstaller URI scheme. During your normal release pipeline you would have to add a step that publishes the file to OneDrive or SharePoint to a known location, and the way to do it would depend on how you are building (e.g. Azure Pipelines).

from msix-packaging.

In the general sense, I'd like to put my apps behind AAD-authenticated page/site.

I assumed Visual Studio would also need to know my intent of that because the msixauth parameter would have to be added somewhere as part of the msix generation/publishing process, correct? I am I correct to assume that the update location for the app would need authentication?

I would like to find out more about what you mentioned about OneDrive/SharePoint as that was something I was also curious about doing. Can you elaborate?

from msix-packaging.

The msixauth parameter is not something you need to worry about as part of the MSIX package creation.

If you need authentication to access the place you're publishing the package to, you will need to deal with that for both publishing and installing/updating, but how you authenticate would be different in each case. For publishing, it would depend on the infrastructure you use in your build process. Whether that is a manual process, or automated through Azure Pipelines or similar, but each tool would have its own way of authenticating.

OneDrive and SharePoint are places where you can put your MSIX package (or .appinstaller file), and have App Installer (the UI you see when installing a package) authenticate to access it.

from msix-packaging.

Okay. That answers one of the questions.

So my process is currently manual. I'm taking that approach for now so I can step through and understand it. So let's say I'm at a point where my package is signed and published from VS and I can put it in a SharePoint Online share (a location that will require users to authenticate with a work account).

ms-appinstaller:?source=https://[tenant].sharepoint.com/sites/IT/Shared Documents/Apps/APP/APP5WTS.appinstaller&msixauth=aad

When I actually us the msi-appinstaller URI above it and run it, this is what I get:

I sign in and successfully authenticate, but eventually get this:

What am I missing?

Also, with the authentication in place, how does the update process look like in the case of a silent update? is this log-in box going to pop up?

from msix-packaging.

I tried republishing since I may have left the bad URL in the Visual Studio publish wizard. After that, it seems the message is now different, but still not resulting in a successful install:

from msix-packaging.

I just found out I can get the app install using the msixbundle linked instead of the appinstaller, but it doesn't look like the update check at startup is working.

ms-appinstaller:?source=https://[tenant].sharepoint.com/sites/IT/Shared Documents/Apps/APP/APP5WTS_3.3.276.0_Test/APP5WTS_3.3.276.0_x64_arm64.msixbundle&msixauth=aad

from msix-packaging.

@florelis, I sent a follow-up question to Matteo: is it safe to assume that the changes that need to happen manually to the things generated by VS are just the links to the index.html or is it something in the .appinstaller or .msixbundle files?

from msix-packaging.

just the links to the index.html

Not sure what links you mean here

But yes, you should not need to change anything on the .appinstaller or .msixbundle files for auth to work. Unfortunately, it looks like the combination of .appinstaller and msixauth doesn't work correctly on the App Installer side, regardless of your app.

from msix-packaging.

Okay. Again, given the pressure (lack of time) imposed by Store for Business going away this quarter, how can I get this moving forward? Can this get more attention from higher-ups?

from msix-packaging.

@florelis, is an update to App Installer / winget what is needed for this to be handled properly or is there more to it?

from msix-packaging.

Yes, this needs an update to App Installer. Unfortunately, I don't have an ETA of when that will be available.

from msix-packaging.

@florelis, I'm glad the retirement of Store for business has been postponed, but how can I keep working on this? I don't want to lose focus on this. Does this have the attention/priority needed internally?

from msix-packaging.

@florelis, are you still able to help with this?

from msix-packaging.

I've been looking into this recently. I think there is a way to make it work if you hold it just right.

Let's say your .appinstaller file is going to be at https://contoso.com/app.appinstaller and the MSIX package at https://contoso.com/app.msix. You need to specify those two URIs in the .appinstaller file. If any of them is behind AAD auth, you will need to add the msixauth parameter in the URI within the .appinstaller file. So, for the .appinstaller file you'd instead use https://contoso.com/app.appinstaller?msixauth=aad and for the package itself, https://contoso.com/app.msix?msixauth=aad.

Note that if the URI already has query parameters, instead of ? you'd use &. So, instead of https://contoso.com/app.msix?foo=1 you'd use https://contoso.com/app.msix?foo=1&msixauth=aad. Also, since this is going into an XML file, you'll have to escape the & as &, like https://contoso.com/app.msix?foo=1&msixauth=aad. Having the msixauth parameter in there is what would help deal with auth during updates.

To install the app for the first time, you can use the ms-appinstaller URI scheme, or download the file and double-click it. If the initial file is in a location that doesn't need auth, you won't need the msixauth parameter when you call this, but you'll still get the auth prompt after you are redirected to the URIs from the .appinstaller file.

from msix-packaging.

I think I've taken a couple steps back. I think I've got this setup as you have above, but I'm running into the error shown here again: #567 (comment)

Can you review this appinstaller file?
TEST.appinstaller.txt

from msix-packaging.

The AppInstaller and MainBundle elements look right to me. For the dependencies, I think you'd also need to add ?msixauth=aad at the end, but I'd suggest trying to get it working without any dependencies first to reduce the number of variables.

I'm assuming the Uri listed for the AppInstaller element is where the file you shared is? If it points to something else, it would use that other file.

How are you trying to run it? With ms-appinstaller or download+click?

You can find the logs for the App Installer UI at %localappdata%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState. The logs around accessing the URIs are not that detailed, but it can give us an idea of where this is failing.

from msix-packaging.

The AppInstaller and MainBundle elements look right to me. For the dependencies, I think you'd also need to add ?msixauth=aad at the end, but I'd suggest trying to get it working without any dependencies first to reduce the number of variables.

I commented out the dependencies

I'm assuming the Uri listed for the AppInstaller element is where the file you shared is? If it points to something else, it would use that other file.

Correct. That is the intent.

How are you trying to run it? With ms-appinstaller or download+click?

Using the protocol with the following or download+click doesn't work with the .appinstaller

ms-appinstaller:?source=https://subsite.sharepoint.com/sites/IT/Shared%20Documents/Apps/APP/APPWTS.appinstaller?msixauth=aad

ms-appinstaller:?source=https://subsite.sharepoint.com/sites/IT/Shared%20Documents/Apps/APP/APPWTS.appinstaller&msixauth=aad

Using the protocol with the following or download+click works with the .msixbundle

ms-appinstaller:?source=https://subsite.sharepoint.com/sites/IT/Shared%20Documents/Apps/APP/APPWTS_3.3.285.0_Test/APPWTS_3.3.285.0_x64_arm64.msixbundle&msixauth=aad

You can find the logs for the App Installer UI at %localappdata%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState. The logs around accessing the URIs are not that detailed, but it can give us an idea of where this is failing.

FYI, this is reminds me of my last email to Kevin Larkin where I mentioned there is also a situation where if the PC is signed in to a different tenant other than the target, the AAD sign in prompt will default to that tenant rather than the intended one (where the appinstaller/msxibundle is). Can I forward that email to you? I am unsure if I'm going to get a response from him.

AILog.txt

from msix-packaging.