Cannot save at all about collabora-mattermost HOT 24 OPEN

Same Problem here.
I'm running Mattermost on Gitlab, an a local test-Installation of Collabora.

from collabora-mattermost.

Same issue here .. but i do see some warnings in the logs when trying to save:
WRN Invalid or missing JSON in WOPI::PutFile HTTP_OK response.| wsd/Storage.cpp:1448 from collabora

and {"level":"warn","ts":1632748705.456574,"caller":"app/session.go:89","msg":"Error while creating session for user access token","error":"createSessionForUserAccessToken: Invalid or missing token., resource: UserAccessToken id: token=<redacted>"} from mattermost

Local test install of Collabora code and mattemost whit 1.1.0 version of collabora plugin.
Also tested with plugin build from git master branch.
Same Collabora installation works fine with nextcloud. Saving in nextcoud does not trigger the warningn messages in the log file.

from collabora-mattermost.

Can we get more info - for example a good stack-trace of where this Error comes from ? that would be quite helpful. The proximate cause is in Mattermost - but presumably we're passing in some wrong authentication pieces from higher up the stack. Getting those stack frames would be most helpful. Presumably breaking on session.go:89 and following https://golang.org/doc/gdb with a 'bt' to generate a backtrace and pasting in would be really useful.

Thanks!

from collabora-mattermost.

@mmeeks does this help:

Thread 7 "mattermost" hit Breakpoint 1, github.com/mattermost/mattermost-server/v5/app.(*App).GetSession (a=0xc003ee4370, token=..., ~r1=<optimized out>, ~r2=<optimized out>)
    at github.com/mattermost/mattermost-server/v5/app/session.go:89
89	in github.com/mattermost/mattermost-server/v5/app/session.go
(gdb) bt
#0  github.com/mattermost/mattermost-server/v5/app.(*App).GetSession (a=0xc003ee4370, token=..., ~r1=<optimized out>, ~r2=<optimized out>)
    at github.com/mattermost/mattermost-server/v5/app/session.go:89
#1  0x00000000020b68ed in github.com/mattermost/mattermost-server/v5/app.(*Server).servePluginRequest (s=0xc001442d80, w=..., r=0xc003deb600, handler=
    {void (github.com/mattermost/mattermost-server/v5/plugin.Context *, net/http.ResponseWriter, net/http.Request *)} 0xc002acf840)
    at github.com/mattermost/mattermost-server/v5/app/plugin_requests.go:145
#2  0x00000000020b4e4f in github.com/mattermost/mattermost-server/v5/app.(*Server).ServePluginRequest (s=0xc001442d80, w=..., r=0xc003deb600)
    at github.com/mattermost/mattermost-server/v5/app/plugin_requests.go:45
#3  0x0000000002162311 in github.com/mattermost/mattermost-server/v5/app.(*Server).ServePluginRequest-fm (w=..., r=0xc003deb600)
    at github.com/mattermost/mattermost-server/v5/app/plugin_requests.go:23
#4  0x00000000007179a4 in net/http.HandlerFunc.ServeHTTP (f={void (net/http.ResponseWriter, net/http.Request *)} 0xc002acfa38, w=..., r=0xc003deb600) at net/http/server.go:2049
#5  0x0000000001a273f3 in github.com/gorilla/mux.(*Router).ServeHTTP (r=0xc00011e600, w=..., req=0xc003deb400) at github.com/gorilla/[email protected]/mux.go:210
#6  0x000000000071b063 in net/http.serverHandler.ServeHTTP (sh=..., rw=..., req=0xc003deb400) at net/http/server.go:2867
#7  0x000000000071648d in net/http.(*conn).serve (c=0xc0049e4640, ctx=<error reading variable: access outside bounds of object referenced via synthetic pointer>)
    at net/http/server.go:1932
#8  0x0000000000474c81 in runtime.goexit () at runtime/asm_amd64.s:1371
#9  0x000000c0049e4640 in ?? ()
#10 0x0000000003100998 in timerCtx,context.Context ()
#11 0x000000c003ebcb00 in ?? ()
#12 0x0000000000000000 in ?? ()

i'm not a experienced gdb user and i might need more directions :D

from collabora-mattermost.

i realise i did not follow your instructions, @mmeeks .. :D
i'll retry in a couple of hours.

from collabora-mattermost.

It looks helpful =) but I expect that this entry point is used by many callers - and we really want to break only when this assert fails. Quite possibly we don't need to insert a breakpoint, and go will trap / raise a signal for gdb when the assert fails - if so, that would be ideal. Thanks ! =)

from collabora-mattermost.

The Mattermost-Log says after editing and saving a doc:
(Token ist removed)

{"level":"warn","ts":1633512010.3274574,"caller":"app/session.go:89","msg":"Error while creating session for user access token","error":"createSessionForUserAccessToken: Invalid or missing token., resource: UserAccessToken id: token=XXXXXXXXX"}

from collabora-mattermost.

@notaus557 thanks for that - however, we don't call createSessionForUserAccesToken from collabora-mattermost as far as I can see - so, getting a full stack-trace would be extremely helpful. Possibly this page:

https://docs.mattermost.com/configure/configuration-settings.html

which has a Stacktrace setting you can set to true might help - can we turn the log level right up too to get more data?

Thanks.

from collabora-mattermost.

@mmeeks i could not reproduce the behaviour when mattermost was using local storage.. which makes me think mattermost <-> s3 is the real problem..
ill reenable s3 storage and enable the stacktrace setting in mattermost, and see what i can find.

@notaus557 are you also using s3 storage in mattermost, if so what provider do you use?

from collabora-mattermost.

@mmeeks after switching back to s3 storage for mattermost, the problem reappears .. :)
Im guessing the collabora plugin is of the hook then.

We are using ceph as our s3 provider, ill try to reproduce this on aws bucket storage as well.

from collabora-mattermost.

@notaus557 are you also using s3 storage in mattermost, if so what provider do you use?

We use Local Storage. (Centos 7 VM) on the same machine as the Gitlab EE Instance.

from collabora-mattermost.

@notaus557 what is you "Local storage directory:" set to in mattermosts config?

from collabora-mattermost.

@notaus557 what is you "Local storage directory:" set to in mattermosts config?

it's the gitlab suggested default setting
/var/opt/gitlab/mattermost/data

data has mattermost:root owner, I also tried with 777, but no change.

from collabora-mattermost.

it's the gitlab suggested default setting /var/opt/gitlab/mattermost/data

Ah ok,
I would try to temporarily move the storage path to /tmp and then do some testing @notaus557
that would exclude all permission related problems. :)
If moving to /tmp works for you, you know there is a permission problem in the gitlab suggested default path.
If saving to /tmp does not work, there might be another issue..

from collabora-mattermost.

would try to temporarily move the storage path to /tmp and then do some testing

sorry to say, no change with data in /tmp

from collabora-mattermost.

Any fixes , i'm using s3 storage

from collabora-mattermost.

Hello everyone, any news for this issue?
Thank you.

from collabora-mattermost.

Anyone can try to complile last plugin commit? Maybe can solve the problem?

from collabora-mattermost.

I use 1.1 version and change some code in plugin.go as workaround, in my case backstore is s3 minio.
import v6 package:

"github.com/mattermost/mattermost-server/v6/model"
"github.com/mattermost/mattermost-server/v6/plugin"
"github.com/mattermost/mattermost-server/v6/shared/filestore"

then repace the "save local file" section:
https://github.com/CollaboraOnline/collabora-mattermost/blob/1.1.0/server/plugin.go#L202
with below:

// save file to S3 storage
	if r.Method == http.MethodPost {
		var settingConfig model.FileSettings = p.API.GetConfig().FileSettings
		body, bodyReadError := ioutil.ReadAll(r.Body)
		if bodyReadError != nil {
			p.API.LogError("Error occured when reading body:", bodyReadError.Error())
			return
		}
		settings := filestore.FileBackendSettings{
			DriverName:              *settingConfig.DriverName,
			Directory:               *settingConfig.Directory,
			AmazonS3AccessKeyId:     *settingConfig.AmazonS3AccessKeyId,
			AmazonS3SecretAccessKey: "your secret key", // api return content is sanitized, so it returns ********, rather than secret string
			AmazonS3Bucket:          *settingConfig.AmazonS3Bucket,
			AmazonS3PathPrefix:      "", //api rerturns nil
			AmazonS3Region:          *settingConfig.AmazonS3Region,
			AmazonS3Endpoint:        *settingConfig.AmazonS3Endpoint,
			AmazonS3SSL:             false, //api rerturns nil, model/config.go: ToFileBackendSettings()
			AmazonS3SignV2:          false, //api rerturns nil, model/config.go: ToFileBackendSettings()
			AmazonS3SSE:             false, //api rerturns nil, model/config.go: ToFileBackendSettings()
			AmazonS3Trace:           false, //api rerturns nil, model/config.go: ToFileBackendSettings()
		}
		s3, err := filestore.NewS3FileBackend(settings)
		if err != nil {
			p.API.LogError("Error occured when create s3 client: " + err.Error())
			return
		}
		_, err = s3.WriteFile(bytes.NewReader(body), fileInfo.Path)
		if err != nil {
			p.API.LogError("Error occured when writing contents to file: " + err.Error())
			return
		}
	}

from collabora-mattermost.

Sorry but doesn't work with local storage.
this is the message:
#34 (comment)

same collabora istance with nextcloud works correctly.

from collabora-mattermost.

I can confirm this issue:

warn  [2022-09-16 11:58:33.099 +02:00] Error while creating session for user access token caller="app/session.go:89" error="createSessionForUserAccessToken: Invalid or missing token., resource: UserAccessToken id: token=eyJhbGciOiJIUzI...."
warn  [2022-09-16 11:58:33.121 +02:00] Error while creating session for user access token caller="app/session.go:89" error="createSessionForUserAccessToken: Invalid or missing token., resource: UserAccessToken id: token=eyJhbGciOiJIUzI...."

Mattermost 7.3.0 Debian / Collabora Plugin 1.1.0

COOLWSD Version:
22.05.6.1

LOKit Version:

Collabora Office 22.05.6.1

Debian GNU/Linux 10 (buster)

Viewing / Editing flles works, but we cannot save changes.

Sep 16 12:02:36 sblxcollabsrv1 coolwsd[4008]: wsd-04008-04035 2022-09-16 12:02:36.128064 +0200 [ websrv_poll ] INF  WOPI host did not pass optional access_token_ttl| wsd/FileServer.cpp:928
Sep 16 12:02:36 sblxcollabsrv1 coolwsd[4008]: wsd-04008-04035 2022-09-16 12:02:36.147777 +0200 [ websrv_poll ] INF  #19: WebSocket version: 13, key: [HNC...d6yD==], protocol: [chat].| net/WebSocketHandler.hpp:910
Sep 16 12:02:36 sblxcollabsrv1 coolwsd[4008]: wsd-04008-04035 2022-09-16 12:02:36.147863 +0200 [ websrv_poll ] INF  URL [https://mm.domain.com/plugins/com.collaboraonline.mattermost/wopi/files/reqkhkkftjyabc...pw?access_token=eyJhbGciOiJIUzI...&access_token_ttl=0] for WS Request.| wsd/COOLWSD.cpp:4548

from collabora-mattermost.

@yunusem Can you help us?

from collabora-mattermost.

@sarz4fun Hi, I just quickly read the discussion from top to bottom, the only outcome I can think of is that you need a small debugging about your local storage when the saving action is happening. So, in my opinion, it is not related to any session management since editing works, and this comment should have helped. Maybe try harder with file and path permissions?
I mean did you try to write to "the file" by hand (from shell or terminal) while you are the "mattermost" user?
I hope this helps, otherwise, I have no other idea :)

from collabora-mattermost.

hello, i have tried with 777 permissions to attachment folder but no luck. Invalid or missing token error on saving.

from collabora-mattermost.