OnlyOffice support generates document key of 0000000000000000000000000000000000000000 for emtpy files

[mdovey]

If a file is empty (i.e. file size of 0), for instance if you have created a new file in seafile, the key passed to OnlyOffice is always 0000000000000000000000000000000000000000

For instance the script created looks like:

var config = {
"document": {
"fileType": "docx",
"key": "0000000000000000000000000000000000000000",
"title": "yetanother.docx",

The problem is that this creates a key clash if you attempt to open multiple empty files, as OnlyOffice thinks that these are the same file.

[mdovey]

sorry, I've just notice that 5119990 fixes this

[mdovey]

Sorry, I misread the diff for 5119990

this update introduces the problem rather than fixes it!

the new use of obj_id generates a key of all zeros, (as well as a 40 character string which exceeds the stated maximum length of 20 in the OnlyOffice API documentation), whereas the older gen_token generates a unique key even for empty files.

Perhaps line 458 should be

doc_key = gen_token(20)

[shoeper]

It should be doc id as long as it's not zero.

[TMHBOFH]

@mdovey
I have also a similar issue.
I create a new file over web-site, these has a size of 9K and regular document key.
My problem is all new files has the same document key and OnlyOffice does not like that.

Did you test in a new installed?

[shoeper]

Possibly it would be a good idea to make a hash from the document id and path. Because only one file can be a a specifc path this should be very very unlikely to collide.

[TMHBOFH]

Ok please check a possible workaround, but i'm not sure if this the best way. I hope a dev can check this.
A small feedback would be nice

[xiez]

Guys, sorry for the delay! I will check it today.

[xiez]

Here is my patch https://github.com/haiwen/seahub/pull/1616/files, you guys please take a test.

@TMHBOFH your workaround is okay, but it's better to add repo_id into that hash stuff.

[mdovey]

My concern with this code is that although the hash function should produce an id with low probability of a clash, there is no such assertion about a sub-string of that id.

A better approach would be a hash function which generated a 20 char hexdigest directly (i.e. an 80bit hash) - however, the techniques for this do not look simple (https://crypto.stackexchange.com/questions/3558/are-there-hash-algorithms-with-variable-length-output)

I'm afraid I'm not an expert to know if truncating the 32 character string to 20 characters significantly increases the likelihood of clashes.

[TMHBOFH]

@xiez Thanks i have tested and it works fine

@mdovey i am also not a crypto expert, but i think likelihood of clashes is very very unlikely.

[anndro]

Adding obj_id into hash produces new errors, While 2 people work on same shared document and one of them leave onlyoffice calls save callback and obj_id changes. Also document key changes. If one of these users refresh the page now they have 2 different document on onlyoffice but 1 document on seafile. Seafile save this documents to same path. Last exited user will win and his revision will be saved.