Forum Discussion
StephenRice
Microsoft
MicrosoftNew OneDrive & SharePoint Feature: Fixing Unhealthy Sharing Links
Hi all,
I wanted to drop by and let interested folks know about a new feature we are rolling out to help users deal with "unhealthy" links! We've seen a few cases recently where a user makes so...
StephenRice,
Good day. Do you know of any blog or documentation that covers a few common ways links can become broken? I'm currently working on a ticket with Microsoft for just that. A user shared a link with non-company users, it works for a long while, she changes the name, and sometime after that the company and my user finds that the document is broken; however, other links to the document work. I could give more information, but I'm not asking you to look into my problem, just if your expertise may reveal documents not easily found.
Thank you for your time.
Sincerely,
Daniel Smith
- StephenRice
Hi dsmith_icona,
This post is the only "documentation" that we have at the moment. The particular case we are covering here occurs when advanced users play with the advanced permissions API's around a file/folder/document library. The short but technical explanation is that a sharing link consists of a link object that is tied to an ACL on the item and when the ACL gets removed (but the link is not), it can cause some pretty broken scenarios. This only occurs if you use lower level permissions API's though as all of our UI for sharing/unsharing files will always clean up both pieces.
Renaming a file wouldn't cause this to occur though so working through this with support is likely your best bet. Thanks!
Stephen Rice
Senior Program Manager, OneDrive
Hi Stephen,
I am working with the SP REST api to programmatically remove individual users from a secure link.
I have noticed some odd behaviour when multiple API calls are made in parallel, each trying to remove access for a different user against the same SecureLink.
Sometimes this results in a SecureLink turning "unhealthy", showing the red "broken link" warning text in the UI.
I am also intermittently (but regularly) seeing scenarios where I am trying to remove user A and B, and even though each request results in a HTTP 200 response (with no error in the response body), it appears as if the removal of user B reinstates user A against the link. Note that this only happens if the API calls are made in parallel. If the same API calls are made in sequence then everything works as expected. To me this suggests there is some sort of concurrency issue on the server side.
I am only using the /ListItemAllFields/SecureLink endpoint, using the inviteesToRemove bit in the JSON payload to indicate which user to remove. I am not using any API endpoints that directly manipulate the underlying ACLs.
I also think this issue could arise if multiple end users are modifying the same secure link through the browser and they happen to submit their changes at the same time, given that this operation uses the same API endpoints.
Let me know if you need me to provide more info or some code to reproduce this issue.
Thanks,
Jaap
This sounds like exactly what I too am looking for. However I cannot find anywhere that the inviteesToRemove syntax is explained. What call are you using for that?
