Open stevebeauge opened 1 year ago
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
Hi @stevebeauge, about a year ago I raised a support ticket with Microsoft regarding this exact scenario and got the following final response after a lot of discussions back and forth:
"As P... mentioned I took ownership of this case as he is out of office, but before he left he chased Engineering to ask them to come to a conclusion on this request. They just did: The current behavior is expected and is a consequence of the current design of the CreateCopyJobs API, which does require the elevation of privileges to work correctly. This design has always been present, is expected, and your remote event receiver must handle this possible scenario. As P... suggested, should you need to connect to SharePoint on those events in the remote event receiver, you should do so using app-only permissions."
I then also raised some concerns on how to validate that the call was valid since there is no token to validate and got the following response:
"As per your concerns: How do you propose I could verify the user using an app-only request to SharePoint when I don’t have a token to validate but rather just the username which could easily be spoofed in the request? And sure the request could come from a malicious server but the token would still need to be valid since it is validated by the TokenHelper class when the SharePoint context is being constructed or are you talking about something else? The preferred method would be adopting web hooks as this is the latest technology to achieve the results you intend, as they have replaced Remote Event Receivers, as documented here: Important As of January 2017 SharePoint Online does support list webhooks which you can use instead of "-ed" remote event receivers. Also please take into consideration that Remove Event Receivers were created for the older legacy models, such as SharePoint Add-Ins, and it the alternative shared previously by my colleague is explained here: Event receivers added to host web without app context, for example with SharePointOnlineCredentials or other means, will not return access token and you'll have to access the host web with app-only access token In your scenario if you want to keep such a solution with the change we suggested, and make sure there aren't any concerns, the alternative would be to, before any action, verify and confirm the change in SPO, that it actually happened, in that way, any theoretical issue would be mitigated."
As you can see they state that this is by design.
Just posting this here for your knowledge not as a real solution and I am still hoping for someone to provide a better solution for this issue. I feel that webhooks are not a replacement for remote event receivers, just a complement, since there are a lot of scenarios where we need synchronous event handling.
Thanks @patrikhellgren for your feedback.
Since webhooks do not support -ing event, I can't migrate to webhook easily (not mentionning the latency of webhooks that can cause business issue). Hopefully someone will have a workaround to provide (even thought I'm not confident)
Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
SharePoint Add-ins
Developer environment
Windows
What browser(s) / client(s) have you tested
Additional environment details
SP Addin built with .Net 4.8 and VS 2022
Describe the bug / error
Remote Event Receivers allows to intercept item updating or item adding event, and item updated or item added event.
However, these event has empty context token when action is issued from another site collection, especially using the standard OOB "Copy to action" from a document library. These leads to issues when some operation has to be made on the target site collection.
I have two site collections (let call them
src
anddest
)In the
dest
site collection I have a remote event receiver that triggers whenever a document is updated in the default document library (ItemAdded, ItemAdding, ItemUpdated and ItemUpdating event are tracked).This works perfectly when I work whithin the site collection
dest
(drag and drop file from windows explorer or using the "copy to" action within the same site collection.However, if I copy a file from
src
todest
using the OOB copy to action, the RER fails, having in the payload this error:After some tests, I land to the conclusion this is due to the browser session creating an auth token for the site
src
to call the copy file api.Then the RER triggers using the context token for site
src
not sitedest
and fails because of that.How to overcome this issue ?
Some details:
AppInstalled
event to register the receivers onto the host site's document library under the RER app context.SPRemoteEventProperties.ErrorMessage
node.app
package), uploaded in the site collection's app catalog, then activated (from add an app menu)the manifest declare this permissions request :
As I said, it's working perfectly when working within the
dest
site.sample SOAP payloads:
Payload of the ItemAdded event, if file copy within the same site collection :
Payload when copied from different site collections :
Differences :
UserDisplayName
andUserLoginName
. When different sites, its system accountContextToken
is provider, no error message. When different sites,ContextToken
is empty, butErrorMessage
contains the errorSteps to reproduce
A full repro sample is available here : https://github.com/stevebeauge/Repro.MissingContext.
Press F5 from the solution to deploy and add the application to a site, a sample MyList library will be created with RER plugged.
Expected behavior
Remote Event Receivers SOAP payloads should contains a valid context token when triggerd by a user.
Whether the action is executed from the site collection or not.