Broken OnlyOffice in Seafile CE 8.0.2

Installing 8.0.2 broke my OnlyOffice integration. Trying to open any document leads to: “Sicherheitstoken des Dokuments ist nicht korrekt. Wenden Sie sich an Ihren Systemadministrator” (in english: “The documents security token is not correct. Please contact your system administrator.”

The security token is defined in seahub_settings.py:
# Enable Only Office
ENABLE_ONLYOFFICE = True
VERIFY_ONLYOFFICE_CERTIFICATE = True
ONLYOFFICE_APIJS_URL = ‘https://mydomain.mydyndns.com/onlyofficeds/web-apps/apps/api/documents/api.js’
ONLYOFFICE_FILE_EXTENSION = (‘doc’, ‘docx’, ‘ppt’, ‘pptx’, ‘xls’, ‘xlsx’, ‘odt’, ‘fodt’, ‘odp’, ‘fodp’, ‘ods’, ‘fods’)
ONLYOFFICE_EDIT_FILE_EXTENSION = (‘docx’, ‘pptx’, ‘xlsx’)
ONLYOFFICE_JWT_SECRET = ‘mySecret’

For OnlyOffice I use a custom local.json where the security token is defined:
{
“services”: {
“CoAuthoring”: {
“sql”: {
“type”: “postgres”,
“dbHost”: “localhost”,
“dbPort”: “5432”,
“dbName”: “onlyoffice”,
“dbUser”: “onlyoffice”,
“dbPass”: “onlyoffice”
},
“redis”: {
“host”: “localhost”
},
“token”: {
“enable”: {
“request”: {
“inbox”: true,
“outbox”: true
},
“browser”: true
},
“inbox”: {
“header”: “Authorization”
},
“outbox”: {
“header”: “Authorization”
}
},
“secret”: {
“inbox”: {
“string”: “mySecret”
},
“outbox”: {
“string”: “mySecret”
},
“session”: {
“string”: “mySecret”
}
}
}
},
“rabbitmq”: {
“url”: “amqp://guest:guest@localhost”
}
}

OnlyOffice docker is started like this:
sudo docker run -dit -p 88:80 -v /home/seafile/conf/local.json:/etc/onlyoffice/documentserver/local.json --restart always --name oods onlyoffice/documentserver

Deactivating the security token brings OnlyOffice back to life, but of course I’m not keen on leaving the access unsecured.

Where should I start investigating?

Can confirm the same issue. Upgrading to 8.0.2 breaks OnlyOffice handling if using a security token.

1 Like

Good to hear that it seems to be a general problem. Did you find any solution?

Not yet. For now, I’ve disabled the security token (my onlyoffice installation is protected by other means so it’s not critical)

I see. Can you give me a hint on how to secure my installation without token?

In my case, everything is behind an nginx reverse proxy, and access controlled by Lemonldap NG websso

A nginx reverse proxy is what I’ve already in use. But in my configuration the document servers undisclosed port is mapped to a subdirectory which is accessible over the inernet:
location /onlyofficeds {
proxy_pass http://127.0.0.1:88/;

Would it be possible to skip this and set localhost:88 as ONLYOFFICE_APIJS_URL in seahub_settings.py?

@Tjelfe and @dani

Ok, I thought I was like LukeSkyWalker in front of the elements…

Meanwhile I filed an issue: https://github.com/haiwen/seafile/issues/2417

Fixed in CE 8.0.3

2 Likes

@Tjelfe Strange, I even get the following error with the 8.0.3-server built:

image

and checking the logs, this time we got some errors:

2021-01-28 20:59:08,710 [ERROR] django.request:222 log_response Internal Server Error: /lib/dc2249b3-2d93-4d39-acce-704b769a0183/file/Docs de Papa/Rellenado Modelo 210 Hacienda/Dudas modelo 210 negativo.docx
Traceback (most recent call last):
  File "/media/sda/seafile/seafile-server-8.0.3/seahub/thirdpart/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/media/sda/seafile/seafile-server-8.0.3/seahub/thirdpart/django/core/handlers/base.py", line 115, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/media/sda/seafile/seafile-server-8.0.3/seahub/thirdpart/django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/media/sda/seafile/seafile-server-8.0.3/seahub/seahub/auth/decorators.py", line 27, in _wrapped_view
    return view_func(request, *args, **kwargs)
  File "/media/sda/seafile/seafile-server-8.0.3/seahub/seahub/base/decorators.py", line 59, in _decorated
    return func(request, *args, **kwargs)
  File "/media/sda/seafile/seafile-server-8.0.3/seahub/seahub/views/file.py", line 786, in view_lib_file
    onlyoffice_dict = get_onlyoffice_dict(request, username, repo_id, path,
  File "/media/sda/seafile/seafile-server-8.0.3/seahub/seahub/onlyoffice/utils.py", line 142, in get_onlyoffice_dict
    return_dict['onlyoffice_jwt_token'] = jwt.encode(config, ONLYOFFICE_JWT_SECRET).decode('utf-8')
AttributeError: 'str' object has no attribute 'decode'

What do you think? Maybe I have something missconfigured.

Did it work with 8.0.1 or 7.1? I just reactivated the secret in seahub_settings.py and restarted the OnlyOffice docker container with the custom local.json.

I pass the jwt token on the environment variable to the container. Here nothing changed and I had the onlyoffice server working integrated in nextcloud. Now I realized that watchtower updated the onlyoffice container this morning and now either the onlyoffice integration works with seafile or nexcloud. Nexcloud shows now the same error that Seafile showed with the version 8.01 (Sicherheitstoken des Dokuments ist nicht korrekt. Wenden Sie sich an Ihren Systemadministrator) Therefore I have to check what’s going on here. The jwt was not changed at all either in nexcloud, nor in seafile. The docker inspect shows the correct jwt -… :anguished:

@Tjelfe yes, it worked good until 8 version.

@Tjelfe I checked and the 8.0.3 (x64) is still not released. How could be sure that it works?

Nexcloud is working now fine with my onlyoffice instance, – I had to “reconfirm” the same very long token, that I had earlier. That’s the same when you do:
sudo docker exec -it onlyoffice-ds cat /etc/onlyoffice/documentserver/local.json

You mean earlier, you “reactivated”, what it does mean exactly? I could try the same in Seafile.

The download link at seafile.com still points to 8.0.2. To get 8.0.3 just change the number in the link. :slight_smile:
I uncommented the line ONLYOFFICE_JWT_SECRET = ‘[my secret]’ in seahub_settings.py. Then I deleted the docker image and downloaded the latest version using
sudo docker run -dit -p 88:80 -v /home/seafile/conf/local.json:/etc/onlyoffice/documentserver/local.json --restart always --name oods onlyoffice/documentserver
The OnlyOffice Version is 6.1.0 as well.

that’s nasty, hahaha
I understood. Ok, I will check uncommenting the line. I though it should work out of the box, but later on can we check why it happens. In my case the container was updated today and I also made before a container restart.

No, still doesn’t work, but I have an idea how to narrow down the problem tomorrow. Like as I said, nextcloud works with onlyoffice good.

Ok, hope you find a solution (fingers crossed). In case I I can be of any use by comparing config files etc., don’t hesitate to ask.

@Tjelfe Today I got another container update for onlyoffice 6.1.1, but still not succesful with Seafile. I will take your offer. Thanks!

I will pass you my onlyoffice server adress and you can test yourself, if you can access. Maybe went something wrong in the rpi-built or we missed something. Let me double check commenting and uncommenting again the jwt-Token…