Sp-dev-docs: Documentation and Discoverability of additional configuration needed to access MS Graph from all native clients (Teams Tabs Desktop/Mobile, SharePoint Mobile)

Created on 26 Jul 2019  路  21Comments  路  Source: SharePoint/sp-dev-docs

Category

  • [ ] Question
  • [ ] Typo
  • [ ] Bug
  • [x] Additional article idea

Background

There seems to be many separate issues in this repo about failure to access Graph API or get graph tokens in native apps. It keeps coming in as separate bug reports for users attempting to use Graph API or tokens in Teams for Desktop, Teams Mobile, SharePoint Mobile, etc. Discussions around this have arisen at least in: #3923 and #2521. It has been known for quite some time that SPFx web parts were unable to access graph from within native apps. The linked comment is from Oct 25, 2018 saying that it was already a known issue by the team, but as far as I can tell it was never added to the documentation. That left developers to create and deploy SPFx web parts and distribute them to their customers without knowing that they would not work in native apps until the customers ran into it. Developers cannot be expected to read through all 787 (at this moment) open issues on this repo to find long-standing and known problems like this.

6 months later, On April 30 we were presented with a temporary, somewhat painful workaround (most of our customers are not json-fluent). That comment was made on an issue specifically about accessing graph from SharePoint mobile app, which means that people like myself coming at this problem from the Teams Desktop app had a difficult time finding it. In that comment we were told

Once we get that confirmation [that the temp fix works] we will proceed on make those steps available to everybody through Public doucumentation.

Confirmation was received from two sources, and we were told on May 2 when the issue was closed that the current work-around would be publicly documented "today" and the documentation would be removed when the promised better way came along that didn't require editing the manifest by hand.

Looking through the docs, unless I missed it, I do not see any of this mentioned in the Teams Tabs docs, in the MsGraphClient docs, in the "Consume the Microsoft Graph in the SharePoint Framework" docs, and specifically not in the section of that article about deploying the solution and granting permissions which contains the most granular instructions for granting API access where I would most likely expect to see the manifest edits documented.

The Ask

Firstly, could we please get the current manifest edit work around, and even more importantly the need for the current manifest edit work around (the fact that SPFx web parts cannot access graph from Teams Desktop, Teams Mobile, or SharePoint Mobile without additional steps) in the docs somewhere? If they are already in the docs somewhere that I did not easily find, perhaps a reference to that place from some of the locations I mentioned above?

Secondly, at this point I'm subscribed to various closed issues that are still being actively commented on as the only places I can get updates about the progress of the promised better fix that doesn't require manual manifest editing. Those issues are specific to either Teams Tabs or the SharePoint Mobile App, and so are not easy to find for people coming from one or the other. They are also very difficult to find because they are closed, and by default GitHub issue searches exclude closed issues.

I created this issue hoping it could be a central (and open issue) for discussion and updates around the promised more automated fix, which impacts all native apps.

Needs auth docs spfx-general to-be-reviewed

Most helpful comment

Hey all, apologies there was some confusion around what tenant we had what in, things seem to be working properly and the reports of breakage were mistaken.

I'm just trying to find a tenant that doesn't have our .sppkg installed to verify that I can use the web parts in teams without doing the manifest edit. Will update when I find a clean environment.

All 21 comments

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

@lucabandMSFT Was this doc'd up publically somewhere?

Been over a month of silence, any updates? I understand that the fix takes time but I'm sort of blown away that this still isn't documented anywhere.

I see #4520 was created recently, and AC you closed it because it was a dupe of #2521... but like I mentioned before, #2521 is closed. People are likely going to check open issues for an ongoing problem rather than going through closed ones...

As this problem continues to come up, we are pointing people at Luca's comment with the work-around. That comment is in an issue marked as CLOSED which makes it very hard to find, and we are treating it as the de-facto documentation for this work-around that people are somehow supposed to discover.

Another note on that work-around, the instructions are out of date! The link Luca provides is to /RegisteredAppsPreview and that URL has been changed to /RegisteredApps. Literally yesterday I had a co-worker in another office call me because he had spent hours and hours trying to figure out why his new SPFx web-part could not access graph from inside Teams. He came across this issue and luckily recognized my name and set up a call with me. He had found the App page, not the app registration page, and had been confused why he couldn't find the manifest section. As the URL provided by Luca wasn't working he wasted a lot of time, and would have wasted much more if he hadn't recognized my name and reached out.

I really REALLY hope we can get this documented soon. It was broken a year ago without any documentation letting devs know. We've had a "temporary" work around for four months without any documentation letting devs know, expecting them to find it in a closed github issue, and even then the instructions are out of date.

I only say this because, like I said, a co-worker came across this exact issue and wasn't able to figure out how to make his web parts work in teams, but if anyone else finds this issue and there is still no official documentation, our guys have a write up on how to install our SPFx web parts with screenshots that we've been trying to keep up-to-date. I do not in ANY way put this here to promote our products, but if you ignore the part about our .sppkg we are at least trying to keep this guide up to date for our customers, and it may be helpful until Microsoft finally documents these steps somewhere.

sorry for my delay in answering.. manual workaround should not be required anymore as we pushed the code change across all our environments in production.

Visiting back the Web API Page in SPO Central Admin should be enough for the solutions to work also in the rich client.

Again, apologies for the radio silence... @TheTedAdams , can you please validate what I mentioned above?
Of course I will wait for updates before closing the issue.
Thanks again

@TheTedAdams I'm only going to address the issue management piece here... not the root issue (I'm letting @lucabandMSFT handle that because frankly, I'm not clear on the problem/fix).

We're trying to get a better management process in place on this issue list and this one just fell through the cracks.

The intention is when a specific PROBLEM (_I'm not using "issue" here as that's something on GH_) is identified, we try to limit it to just one GH ISSUE being open until the PROBLEM is resolved. That follows the general practice so many other GH repos follow. We're trying to avoid multiple open ISSUES that all reference the same PROBLEM.

In this case, 2521 should not have been closed, or should have been re-opened because while it was stated a fix was rolling out, the PROBLEM persisted. As such, I've re-opened #2521.

Thanks so much both of you! I know you are juggling a lot of things and this repo has a metric s-ton of issues.

@lucabandMSFT I would love to validate this, could you provide just a bit of clarity on how I can do that?

Specifically, does the new fix make it so the pre authorized applications entry is no longer needed? Or does the new fix add the pre authorized applications entry automatically.

Specifically, in order for me to validate the fix, should I remove the preauthorizedapplication entry from the manifest in a working tenant and observe that it continues working? Or should I install on a fresh tenant and observe that the preauthorizedapplication entry gets automatically added and it works in teams?

@TheTedAdams: going back to the web API management page in the SPO tenant admin should be sufficient to solve the issue. No new tenant is required. you simply:

  • go to that page
  • ensure that no error message are generated
  • try to use the web part from the rich client

note that it might be required for you to log off / log on back again on the rich client (that depends on how fresh your token is).

Please let me know if this solves the issue.

Hi @lucabandMSFT
It looks like the recent updates has broken the ability to navigate to a tab inside of Teams on Desktop and view the web parts. I have confirmed in two different tenants the web parts are only viewable if you do so from the Teams Web App. However, navigating to the Desktop version of Teams provides the following screenshot.

image

I received the same error message for both tenants I tested this in.

Thanks for your help!

FYI Mick is one of our customer success managers, I asked him to validate the fix, and he has found that without us doing anything, our web parts that were previously working in teams tabs are no longer working...

@micksowl13 , sorry to hear that. Do you have a test tenant you can send me to repro?
the manifest pointed to the error is defintiviely a 3rd party manifest ...

Thanks a lot!

Hey all, apologies there was some confusion around what tenant we had what in, things seem to be working properly and the reports of breakage were mistaken.

I'm just trying to find a tenant that doesn't have our .sppkg installed to verify that I can use the web parts in teams without doing the manifest edit. Will update when I find a clean environment.

Hi @lucabandMSFT, I have not been able to verify that the manual manifest edit is no longer necessary.

On a tenant that hasn't had an SPFx web part installed before I:

  1. Deployed my .sppkg containing my SPFx web parts
  2. Went to API management and approved the pending approval request for Microsoft Graph
  3. Went back to my App Catalog
  4. Switched to Classic mode (As far as I can tell the sync to teams button is not available in any way in the modern mode, is that a known problem?)
  5. Checked my solution and in the FILES menu at the top clicked Sync to Teams
  6. Opened Teams and added my web part as a tab
  7. My Web Part was unable to initialize, and checking our server logs I can see that when it requests a graph token from the tokenprovider it is getting null, which is the behavior we have seen in the past when we did not perform the manifest edit.
  8. Out of curiosity, I checked the manifest for SharePoint Online Client Extensibility Web Application Principal and observed that preAuthorizedApplications is indeed a blank array. I have not made any changes to that manifest.

As far as I can tell, nothing has changed since the last time I did this, and I still need to manually edit the manifest to let my SPFx web part get a graph token in the Teams desktop app.

Can you let me know if I'm missing something here? I see no change, and am not sure what you rolled out.

@TheTedAdams , thanks. Please give me 30 minutes to do some checks and see if there was some issues on our side. Can I please ask you to not modify the manifest in the meantime?
Also, out of curiosity, did you get any message or error in the Web API page in Tenant Admin?

Thanks again

I have not and won't touch the manifest.

No I didn't see any errors visually presented to me. I didn't check the XHR calls tho... so if there was an error that didn't show me anything in the UI I wouldn't know.

Do you want me to revoke the permissiongrant, delete the package, and try again watching the XHR call?

@TheTedAdams , thanks.
We found the issue and we are in the process to fix it right now. Hopefully I should be able to come back here today and ask you to navigate back to the web API page. that should be the only thing needed for you to enable rich client after our intervention from this side.

Stay tuned!

hey @TheTedAdams : can you please

  • re-login to your tenant
  • go to the web api page
  • ensure no error or warnings are displayed
  • go to the Teams rich client and open the tab with the SPFx component in it

and check if that works please?

thanks

That did the trick!

And I can see that your new automated flow has added the preAuthorizedApplications item to the array for me automatically. Awesome!

So for those finding this issue in the future, simply following the steps found here (Specifically steps 5 and 6), and additionally clicking the Sync to Teams button in your app catalog (classic view only?) should be enough to get you going!

Thanks for your help Andrew and Luca, and for putting up with me being a squeaky wheel on this one :)

Thank you for being persistent... I'll go back through the other open issues we have related to this topic and see if we can't clean out those unresolved ones.

@lucabandMSFT For my edification when addressing those other issues: I get from this thread & @TheTedAdams's issue, it addresses the SPFx+MSGraph+Teams desktop client issue... but to understand it completely, does this address the issue where SPFx obtaining an AAD token via AadHttpClientFactory from outside a browser client, such as SP mobile client, Teams desktop client regardless if the SPFx component is/isn't an isolated web part?

@TheTedAdams : as Andrew says, thank you very much for your dedication and feedback. Those are the things the help us react even faster on issues and problems we might have in the system. Please keep sending those!!

@andrewconnell : it does solve the problem for non-isolated web parts. We however still have to fully resolve the accessing tokens from isolated web parts on rich clients.

That fix is still not deployed 100%.

@lucabandMSFT @andrewconnell When will we have a fix for loading Isolated webpart in rich clients.
refer: #4669

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues

Was this page helpful?
0 / 5 - 0 ratings