Also implementing the Cobalt approach to edits and like Julia it stops at a "cant edit screen" even after lockingstore callbacks including co-author etc.
What I have found however is the log system for OWA reveals quite considerable detail about what the OWA server is attempting to do.
C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS
I can see from these logs it complains about a missing access token, by providing
&access_token=1&access_token_ttl=0
to the end of the wopi url this error goes away.
I also tested many of the file info fields and was able to see how the OWA server caches information. If we keep changing the cfi.Version
FileInfo info = new FileInfo("C:\\WOPI OWA WORD EDITOR\\OWA_Source_Documents\\" + fi.Name);
cfi.Version = info.LastWriteTimeUtc.ToString("s");
we get a fresh cached item each time we change the files contents via normal word.
These also affect the View mode for Word and I suspect will lock us out of the word edit mode but since I don't have that working I cant tell yet.
cfi.SupportsCoauth = true; // all three (3) needed to see the edit in browser menu in view mode .
cfi.SupportsCobalt = true; // all three (3) needed to see the edit in browser menu in view mode .
cfi.SupportsFolders = true; // all three (3) needed to see the edit in browser menu in view mode .
cfi.SupportsLocks = true;
cfi.SupportsScenarioLinks = false;
cfi.SupportsSecureStore = true;
cfi.SupportsUpdate = true;
This one locks out the word edit function and unless you update the version of the file it will stay locked even if you change it back to false.
cfi.WebEditingDisabled = false;
Roger Hogg