microsoft
How does msixauth work?
The docs I found regarding msixauth seems lacking. https://github.com/microsoftdocs/msix-docs/blob/main/msix-src/app-installer/app-installer-authentication-manager--overview.md
How can I get Visual Studio to publish assets/packages with it?
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).
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?
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.
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?
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:
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
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.
@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?
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.
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?
@florelis, is an update to App Installer / winget what is needed for this to be handled properly or is there more to it?
Yes, this needs an update to App Installer. Unfortunately, I don't have an ETA of when that will be available.
@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?
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.
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: https://github.com/microsoft/msix-packaging/issues/567#issuecomment-1449078791
Can you review this appinstaller file? TEST.appinstaller.txt
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.
The AppInstaller and MainBundle elements look right to me. For the dependencies, I think you'd also need to add
?msixauth=aadat 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
Urilisted for theAppInstallerelement 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-appinstalleror 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.
I've revisited code signing and distributing apps via this method and I think the update check and authentication in the app launch appears to be working now. 🎉🎉
Hi, @myokeeh and @florelis. Were either of you ever able to figure this out? I am trying to host my .appinstaller and .msixbundle files in an Azure Web App that has AAD auth enabled.
In my .appinstaller file, I added ?msixauth=aad to the end of the uris for the .appinstaller and .msixbundle files as you did.
If I disable AAD auth for the web app, I can download+click the .appinstaller file just fine. However, as soon as I enable AAD auth this no longer works. I get the same error as you: "An error occurred while attempting to authenticate. The user account does not have access to the target resource...".
Accessing the .msixbundle file works fine but I would like to be able to access the .appinstaller file so that the app can check for / receive auto updates.
Is there still no way to securely host .msixbundle and .appinstaller files behind AAD auth?
You have to host the files in either SharePoint/OneDrive or Azure Blob Storage and use URIs to that. These are the only two places that currently work for msixauth.
App Installer knows how to authenticate with specific API endpoints, and those are the only ones it sends the token to. If you use an endpoint it doesn't know how to handle, it won't send the auth token and you will get that error about not having access, even if your account does have access to it.
You have to host the files in either SharePoint/OneDrive or Azure Blob Storage and use URIs to that. These are the only two places that currently work for msixauth.
App Installer knows how to authenticate with specific API endpoints, and those are the only ones it sends the token to. If you use an endpoint it doesn't know how to handle, it won't send the auth token and you will get that error about not having access, even if your account does have access to it.
Where are these requirements documented?
