User Profile
fstephane
Copper Contributor
Joined 3 years ago
User Widgets
Recent Discussions
OneDrive Sharing and Graph "/invite" Endpoint Now Creating Guest Users?
I have an application that integrates with OneDrive via the Graph API, and leverages OneDrive sharing features. Recently I got a new Microsoft E5 dev license, and I've noticed that the sharing workflows and API results are different on this license than on my previous license, and the enterprise licenses of my clients that use the application. All instances are using v1 of the API. On my new license, when I share a OneDrive file/folder using the "/invite" endpoint of the API, it adds the external email I'm sharing with as a Guest on my M365 tenant. It did not do this before. The initial result of the API call to the /invite endpoint is the same as it was previously: [{ 'roles': ['read'], 'grantedToIdentities': [{ 'user': { 'email': '<external email>' } }], 'invitation': { 'signInRequired': True }, 'link': { 'type': 'view', 'webUrl': '<link URL>' } }] However, if I share another file/folder with the same external email, the response is different: [{ 'id': '<permission ID>', 'roles': ['read'], 'grantedTo': { 'user': { 'email': '<external email>', 'displayName': '<external email (minus domain)>' } } }] As you can see, the response now contains "grantedTo" instead of "grantedToIdentity". The response also does not contain a link URL, and I need to perform an extra API call on the permissions of the shared item in order to find the link. This response format matches the responses I expect when I share with internal emails on my tenant, and I can see in the admin centre that the external email has been added as a Guest user. With my old license, and my clients' licenses, external recipients were not added as guests on the M365 tenant, and sharing multiple drive items with the same external user always returned the same format of API response (always including the link URL). Shared Item Access Workflow With my new license, when I use the link to access the shared item with my external email, I am now prompted to provide permissions to my account for the OneDrive tenant (email and tenant domain redacted here for privacy): I am also prompted to set up MFA: With the previous workflow, I just had to enter my email address, then verify the email with a code. I was not prompted to grant permissions or set up MFA. This seems needlessly complicated for sharing drive items with external users, particularly those that are not tech-savvy. Why is the sharing workflow so different on my new dev license? Can I adjust the settings on my tenant to prevent this, or is this how sharing will work going forward? If so, when can I expect this to change for my clients' license? I see no mention of this in the Graph API reference for the Invite endpoint, and I can't find any mention of the change online. I've reviewed the sharing settings in the Sharepoint Admin Centre. However, these are identical to the settings on my old license. I've tried messing with the External Collaboration settings in Entra to prevent guest users from being created, but this prevents me from sharing with external users altogether. I can't find any other settings that may control this behaviour. Please help!Re: OneDrive Sharing Links - Does the "Guest Access Expiry policy" Apply to "Specific People" Links?
I opened a support ticket with Microsoft. At first they were unable to confirm whether the "Guest Access Expiry" policy affects external emails on "Specific People" sharing links if those external emails are not explicitly added as guest users on the tenant. However, they advised me to turn off the "Guest Access Expiry" policy and presented that as a solution to issue. They also advised me to use the "Manage guest expiry" features to extend the access of external emails to my sharing links. However, not all emails that I share with show up in that feature, and I have seen specific emails disappear from sharing link when those emails were not present in the "Manage guest expiry" settings. The support reps remoted onto my computer a handful of times to grab some diagnostic info on my sharing links. However, I did not receive any conclusive findings from their testing. They just continued to refer me to the "manage guest expiry" feature. I asked them a couple more times if they could confirm that the "Guest Access Expiry" policy applies to non-guest external emails on sharing links, but they still would not confirm that point. Since the back-and-forth on the support ticket was going nowhere, I decided to set up a fresh test on my dev account. The results of previous tests I had set up were hard to evaluate, because during one test I had toggled the "Guest Access Expiry" policy after setting up the sharing link, and in a subsequent test I had shared with some of the same emails that I'd previously shared with. I saw emails disappear from both of those sharing links, but I can't be sure that wasn't related to the "Guest Access Expiry" policy. So I set up a new test link with emails that I have never shared with (and that have not been added as guest users - which I have never done in my testing). My "Guest Access Expiry" policy has been turned off for quite some time now and I will leave it off for the duration of my new test. I will continue to monitor this test link over the next few weeks to see if any emails get dropped. If so, I can be pretty confident that there is a bug involved that is unrelated to the "Guest Access Expiry" policy. If no emails disappear from the link, then that may be partial evidence that the "Guest Access Expiry" policy is in fact related. Since the support ticket was going nowhere and my own test will take a few weeks to monitor, I asked that they archive the support ticket. In my review of the ticket I restated that I had not received confirmation yet about whether or not the "Guest Access Expiry" policy relates to non-guest external emails on sharing links. The support rep sent back this response: As checked further, the "guest access expiry" policy in the SharePoint Admin Center only applies to guests who use sharing links or guests who have direct permissions to a SharePoint site after the guest policy is enabled. It does not apply to external emails that are referenced on OneDrive sharing links if those emails are not explicitly added as guest users. So this finally appeared to be direct confirmation that the "Guest Access Expiry" policy should not apply to the external emails I've been sharing with (because they were never added as guests). But now I'm confused as to why they've been advising me to turn that policy off and use the "manage guest access" features to mitigate my issue. Obviously I still have a lot of questions, but I'll see what results my new test yields and will update this post when I have more info.OneDrive Sharing Links - Does the "Guest Access Expiry policy" Apply to "Specific People" Links?
I'm having an issue with a OneDrive integration in an application I'm developing. The integration allows creating "Specific People" sharing links, which are emailed to external users and require them to authenticate their email before accessing the shared file/folder. I have seen in many places that "Specific People" sharing links do not expire. There is no expiry field available when creating the link, and I can't find any expiry settings in the Sharepoint Admin Center that seem to apply to "Specific People" links. However, some of my clients using my OneDrive integration have noticed that many of their "Specific People" links get dropped unexpectedly after a period of one or two months. I have also been able to reproduce this issue in my developer account. There is one setting in the Sharepoint Admin Center that seems like it might apply: Guest Access to a site or OneDrive will expire automatically after this many days Since I've seen many references to the fact that "Specific People" links never expire, I thought this setting was not relevant. I also interpreted "Guest Access" as referring to "Guest Users", which can be added in the M365 Admin Center. My integration does not make any use of Guest Users, so I felt fairly confident that this setting did not apply to my use case. However, I can't seem to find definite confirmation that this "Guest Access Expiry" setting does not apply to "Specific People" links. Since my clients links keep getting dropped, and I've now been able to reproduce this on my own account, I have to assume this is either a bug in OneDrive, or that this setting - or another setting I've not yet found - is causing the links to disappear. I've noticed on my own account that some emails get dropped off of the "Specific People" link after a certain period of time, while others do not. Even though I added all the emails to the link at the same time. This inconsistency makes it seem more like a big than something that is being controlled by an admin setting. Can someone please confirm whether the setting I referenced affects "Specific People" links, and/or if there is another OneDrive/Sharepoint/M365 setting that can cause "Specific People" links to be dropped after a certain period of time? Has anyone else noticed "Specific People" links getting dropped over time, or just one or two of the emails on a multi-person link getting dropped?Re: Sharing Folders with External Users spams Organization Login Prompts
IC_Sid1020 If I recall correctly - it wasn't any changes I made to my account that resolved the issues. I worked closely with MS Support over a period of a few months. They made several rounds of changes on their end and requested that I test them on my end, and we had a handful of sessions where they remoted onto my computer via Quick Assist to observe me creating sharing links and accessing them in different browsers - and to grab diagnostic info. It was a pretty long process. I assumed the changes they made would resolve the issues across the board, so it's disappointing to hear that it's still affecting others. That makes me worried that my company's clients (who use our OneDrive integration to share files/folders with their own clients) may still experience the issue in production.Re: Sharing Folders with External Users spams Organization Login Prompts
IC_Sid Sorry to hear you're still having issues. As I mentioned in my reply to angelmottap, I did some more testing and I did get an O365 login error in one case, but I was not able to reproduce that. Overall it seems to be working as expected for me now. I wonder if there are differences in our O365 plans/setup, or regions that might explain why it's behaving differently on different accounts? To clarify, I'm using OneDrive for Business on a O365 developer license. You may need to open a support ticket with Microsoft and be very persistent. That was the only way I was able to make any progress on my issues... Unfortunately my own ticket has been closed for a long time now and I won't be much help to MS support if I'm not able to reproduce the issues anymore 😞Re: Sharing Folders with External Users spams Organization Login Prompts
angelmottap Sorry to hear you're still having the same issues. I've just tested on a variety of different browsers, private/normal mode, and two different laptops - sharing with O365 and non-microsoft accounts. I did get one case with a link I had sent to an O365 email, where it asked me to sign in with the O365 account and then gave me a similar error to what you received in Case 2. But then I tried again with the same email and it worked fine (can't remember what browser this was in). I tried with that same O365 email across multiple other browsers and modes and it worked in every case - so I'm not sure what happened in that one instance when it threw the error. I am also not getting any login prompt popups, and I don't see any blocked popups showing up in the address bar. Just to confirm - for Case 2, are you signing in with one of the accounts that you shared the OneDrive item with?Re: Sharing Folders with External Users spams Organization Login Prompts
I finally made some progress in getting this issue addressed by Microsoft. I've been working with a new support ticket for a couple months now. They've resolved most of the issues and there's just one remaining edge case I'm trying to get resolved. How it works now: If you have no O365 profile info saved in your browser (or you're in private browsing), you are not prompted to log in anymore. If you do have O365 profile info saved in your browser, you are prompted to log in with your O365 account. However, now it doesn't throw an error if you log in with an account that is not part of the organization that owns the shared resource. Once you've logged in, it does not ask you to log in again. The last issue I'm trying to get resolved: If you access a sharing link that was shared with your specific email, and your email is not an O365 account - you still get the login prompt every time you view a PDF file within the shared folder. There is no way to get the prompts to stop, since you do not have an O365 account to log in with. Hopefully this one will be resolved soon as well!Re: Sharing Folders with External Users spams Organization Login Prompts
I had previously given up on this issue as I was getting nowhere with MS support. However, many of my company's clients are getting frustrated with the confusion this is causing in their own sharing activities, so I have opened up another ticket with MS support. I had a call with a support rep, which I will summarize below: Support rep explained that there are two reasons the login prompts appear when sharing OneDrive folders: Link recipient has O365 credentials stored in their browser. When they access the shared folder, O365 tries to automatically log them in with their stored credentials. That doesn't work (because their account isn't part of the organization), so the pop-up appears prompting them to log in. There are multiple different levels of access/permissions on the shared folder, which creates a conflict. O365 has trouble determining who is accessing the folder and what permissions they should have, so it prompts the user to log in. The support rep explained that there are two "workarounds" to the problem Always access shared folders in a private (incognito) browser session. Create a guest account on your tenant for each user that you share the folder with. This requires sending an invitation by email to the person you're sharing with, and having them accept the invitation. I believe they are required to have their own O365 account. Once the guest account is created, you must re-share the folder with the user's guest account. Now, if the guest uses the new sharing link, they will not receive the login prompt. I explained that these workarounds are not sufficient for our purposes and do not address what I see as a significant bug in the OneDrive sharing model. Microsoft is advertising these sharing links as being able to share with "anyone", and yet the login prompts make it appear as though you need to be part of the folder owner's organization in order to access the folder at all. This is creating confusion and a sense of unprofessionalism with many of my company's clients, who are considering going with a different storage service altogether. When you are sharing OneDrive folders regularly with many different people - as our clients are - it is not reasonable to coordinate these workarounds with each link recipient. It should be Microsoft's responsibility to provide a solution to this issue. The Microsoft support rep said he would discuss with his dev team again. I asked him to keep me updated. Furthermore, after the support call I was able to reproduce the issue in a manner that refutes the supposed causes of the bug: I shared a folder with an anonymous link and there are no other access permissions or links on that folder. I accessed the folder via the anonymous link in a private browser session. I still got the login prompt, even though there should not have been any permissions conflicts and there were no O365 credentials stored in the browser since I was using incognito mode.Sharing Folders with External Users spams Organization Login Prompts
In OneDrive, I can create a sharing link for a folder and set the link so "Anyone with the link can edit". I assume this means that even users outside my organization can edit the folders and files within the shared folder. If I test this with an external account, I'm able to edit the files and folders. However, I'm periodically prompted with a Microsoft login pop-up window. I can ignore/close the login prompt and continue editing the files. However, the login prompt keeps popping up periodically, including every time I refresh the screen. If I try to log in with the external user account, it gives me an error saying I'm not part of the tenant and I need to be added as an external user to the tenant. But then I can still close that and continue editing the files. If I send the invite link for a folder via a graph API call, I'm forced to set the "requireSignIn" property to True in the body of the request. If I set it to False, I get an error: RequireSignIn cannot be false for folders I do not run into the same issue when sharing files. Whether I create the link in OneDrive UI or via the API, the external user does not get hit repeatedly with login prompts. Am I doing something wrong or is this a bug? If sharing a folder is not allowed outside an organization, why does it allow me to create a sharing link where "Anyone with the link can edit"? And why is the external user still able to edit the files despite the repeated login prompts?Graph API - How to Determine Source of OneDrive Permission
When making a call to the OneDrive permission endpoint: /v1.0/me/drive/items/{item_id}/permissions The API returns permissions for the specified item, but also for parents of the specified item, because those can also be used to share the item itself. However, there is no data in the API response to indicate the source of a given permission. Currently, to find the source of a permission, I need to keep executing calls to the permissions endpoint for each parent of the original item, in ascending order, until the given permission is no longer returned. Then I know that the previous item I executed the call for is the one the permission actually belongs to. This is a very hacky solution and extremely inconvenient for my purposes. I've looked for a better solution but haven't found one yet. There has to be a better way than what I'm currently doing...Re: Sharing Folders with External Users spams Organization Login Prompts
ExternalUsers007 Not to my knowledge. It seems like it's been resolved in certain environments, but I still get it regularly in Chrome. It was becoming too onerous to deal with Microsoft support on this, so we will just advise our clients to block the login pop ups if they are a problem.
