Trying to apply a user settings fails with a 400 bad request error

[melslow]

When using /gcal settings and clicking one of the options nothing happens. When looking into the Dev Console you can see the following request being responded to with a error 400.

When inspecting the request you can see that the selected_option is empty.

POST https://mattermost.xxxx.com/api/v4/posts/~redacted~/actions/~redacted~

{"selected_option":""}

The server then responds with:

{
    "id": "api.post.do_action.action_integration.app_error",
    "message": "Action integration error.",
    "detailed_error": "",
    "request_id": "<redacted>",
    "status_code": 400
}

Server version is 8.1.6
Plugin version is 1.0.1

How to reproduce

1. Setup the plugin
2. Go through gcal connect
3. execute gcal settings
4. Click any of the settings
5. Nothing happens. Bad request error in the dev console

Could someone point me to where the code for this functionality lives? I tried looking into it however its not clear to me which part of the code handles this.

[fmartingr]

Hey @mellow420, sorry you are experiencing this!

The code right now lives in a branch under the Microsoft Calendar Plugin: mattermost/mattermost-plugin-mscalendar#267, we are in the process of migrating this into a separate repository entirely.

[melslow]

Alright, I tried having a look but the fact this is split between repo's makes it quite a pain , and since I know very little about GO in general I am not able to figure out how this works.

Would be greatly appreciated if someone could have a look at this.

Obviously willing to provide more info as needed around this issue/

[fmartingr]

Did you have any relevant log messages in your Mattermost instance around the same time the error poped up? We have been using it for a while and didn't receive any report like this.

[MasinAD]

I experience the same problems. I could connect my account but toggling any setting resulted in a 400 status. I checked my Mattermost logs for anything helpful but there's nothing in there besides regular logging. I increased the log level to DEBUG and got

x

A little bit more readable:

{
    "timestamp": "2024-02-01 13:56:09.889 Z",
    "level": "debug",
    "msg": "Action integration error.",
    "caller": "web/context.go:111",
    "path": "/api/v4/posts/x/actions/x",
    "request_id": "x",
    "ip_addr": "x",
    "user_id": "x",
    "method": "POST",
    "err_where": "DoActionRequest",
    "http_code": 400,
    "error": "DoActionRequest: Action integration error., err=Post \"https://x/plugins/com.mattermost.gcal/settings\": dial tcp x:443: i/o timeout"
}

Please don't tell me the IDs are sensitive information and should have been redacted.

[MasinAD]

I found a solution.

Our Mattermost instance runs in an LXC. Actually, it doesn't matter if it's LXC, nspawn, docker, podman. The important part is it's containerized and behind a reverse proxy, thus not reachable from the outside.

The way the plugin works is by requesting an http connection to the Mattermost instance. It resolves the hostname according to the container's name resolution strategy and receives the external IP address. It then tries to connect to this IP address. But the way iptables and NAT work this doesn't work. I'm not deep enough into netfilter, iptables and stuff, but this hairpinning stuff isn't considered with our setup.

A workaround is to put the reverse proxy's local IP address in the /etc/hosts for resolving Mattermost's hostname.

Now the plugin accepts changes to the user settings.

[fmartingr]

I found a solution.

Our Mattermost instance runs in an LXC. Actually, it doesn't matter if it's LXC, nspawn, docker, podman. The important part is it's containerized and behind a reverse proxy, thus not reachable from the outside.

The way the plugin works is by requesting an http connection to the Mattermost instance. It resolves the hostname according to the container's name resolution strategy and receives the external IP address. It then tries to connect to this IP address. But the way iptables and NAT work this doesn't work. I'm not deep enough into netfilter, iptables and stuff, but this hairpinning stuff isn't considered with our setup.

A workaround is to put the reverse proxy's local IP address in the /etc/hosts for resolving Mattermost's hostname.

Now the plugin accepts changes to the user settings.

Yes, this may be it since the actions call URLs using the SITE_URL set up in Mattermost.

it currently works as such:

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: Clicks on setting button
    Note left of Server: From client `$SITE_URL/api/v4/posts/xxx/action/xxxx`
    Server-->>Server: Calls plugin URL to save setting
    Note left of Server: From server`$SITE_URL/plugins/com.mattermost.gcal/settings/xxx`
    Server-->>Client: Updates post with setting saved

Loading

You can either solve it the way you did or by adding A rules to the DNS server being used by your LXC services to point to your reverse proxy, which is what it is expected, at least for servers exposed to the internet.