Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

giphy plugin /gifs functionality not working, but /gif is (tech details attached) #21

Closed
jjtolton opened this issue Jan 3, 2020 · 11 comments

Comments

@jjtolton
Copy link

jjtolton commented Jan 3, 2020

Issue:
the /gifs <query> command will pull up the expected message, however, the buttons do not work as expected (effectively non-functional).

System Details:
image
This is a GCP marketplace version of Mattermost that has been in production approximately 3 months.

What's changed?
I did not observe if the /gifs command was working immediately before this event, however, the /gifs was observed to not be working immediately after I renewed TLS/SSL certifications.

Observations:

Result of executing /gifs test:

image

Result of clicking cancel:

No action. POST request failed, details:
Response

HTTP/1.1 400 Bad Request
Server: nginx/1.16.1
Date: Fri, 03 Jan 2020 14:39:26 GMT
Content-Type: application/json
Content-Length: 173
Connection: keep-alive
Vary: Accept-Encoding
X-Request-Id: hhi8cakb8fgrtjgcz91z96dhfc
X-Version-Id: 5.15.0.5.15.0.decf565a92da6ef0a2c4c9d0d44031e2.false

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

Request:

POST /api/v4/posts/5rmjssbpm7bpfnnykhnks66ymc/actions/bqos84uaafy3uka9kft1hy65ye HTTP/1.1
Host: ****************
Connection: keep-alive
Content-Length: 718
Sec-Fetch-Mode: cors
Origin: https://****************
X-CSRF-Token: ****************
Accept-Language: en
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
Content-Type: text/plain;charset=UTF-8
X-Requested-With: XMLHttpRequest
DNT: 1
Accept: */*
Sec-Fetch-Site: same-origin
Accept-Encoding: gzip, deflate, br
Cookie: ajs_group_id=null; ajs_user_id=%22musn754jtjrfbcux66d8ckr6po%22; ajs_anonymous_id=%2200000000000000000000000000%22; ajs_user_id=%22musn754jtjrfbcux66d8ckr6po%22; ajs_group_id=null; ajs_anonymous_id=%2200000000000000000000000000%22; MMAUTHTOKEN=****************; MMUSERID=****************; MMCSRF=****************

{"selected_option":"","cookie":"****************"}

**************** indicates redacted.

The same type of thing occurs for clicking shuffle and send.

Please let me know if there is any additional information I can provide.

The selected option in the Request seems troubling.

@jjtolton
Copy link
Author

jjtolton commented Jan 3, 2020

Here's what the HTML on the Cancel button looks like, in case the on-click is targeting that:

<button data-action-id="bqos84uaafy3uka9kft1hy65ye" data-action-cookie="****************">Cancel</button>```

@Jodacola
Copy link

I just tested this plugin out on a new Production install of Mattermost (5.19.0) and had the same symptoms: /gifs something would show the expected message, but the buttons would do nothing.

Server logs (via System Console) indicated I needed to update the AllowedUntrustedInternalConnections setting for the app. The POST path in the error had localhost as the domain, and upon reading https://docs.mattermost.com/administration/config-settings.html#allow-untrusted-internal-connections-to, I:

  1. Updated app's config.json file to be to be: "AllowedUntrustedInternalConnections": "localhost".
  2. Restarted the app service via docker-compose restart app
  3. Reloaded the Mattermost UI in the browser
  4. Attempted the /gifs something command again
  5. Tested the buttons

Results showed this resolved my issue: all buttons were working.

Fair warning: I'm very new to using Mattermost and while I'm using a production installation, it's in a test environment. I don't have enough context or knowledge yet to know whether adding localhost to AllowUntrustedInternalConnections is safe enough for true Production use.

@antman1p
Copy link

antman1p commented Feb 28, 2020

I just tested this plugin out on a new Production install of Mattermost (5.19.0) and had the same symptoms: /gifs something would show the expected message, but the buttons would do nothing.

Server logs (via System Console) indicated I needed to update the AllowedUntrustedInternalConnections setting for the app. The POST path in the error had localhost as the domain, and upon reading https://docs.mattermost.com/administration/config-settings.html#allow-untrusted-internal-connections-to, I:

1. Updated app's config.json file to be to be: `"AllowedUntrustedInternalConnections": "localhost"`.

2. Restarted the app service via `docker-compose restart app`

3. Reloaded the Mattermost UI in the browser

4. Attempted the `/gifs something` command again

5. Tested the buttons

Results showed this resolved my issue: all buttons were working.

Fair warning: I'm very new to using Mattermost and while I'm using a production installation, it's in a test environment. I don't have enough context or knowledge yet to know whether adding localhost to AllowUntrustedInternalConnections is safe enough for true Production use.

I am having the same issue and this solution did NOT work for me.

When looking at Chrome's developer tools console I get : fetch_etag.js:30 400 (Bad Request) when I click the "shuffle" button.

{"id":"api.context.404.app_error","message":"Sorry, we could not find the page.","detailed_error":"There doesn't appear to be an api call for the url='/api/v4/posts/xxxxxxxxxxxx/actions/xxxxxxxxxxxxxxxxxxx. Typo? are you missing a team_id or user_id as part of the url?","status_code":404}

@xadium
Copy link

xadium commented Mar 24, 2020

I have exactly the same issue, adding localhost to "AllowUntrustedInternalConnections" did not work for me either - I'm on 5.21.0

Logs from Mattermost show:

{"level":"error","ts":1585071891.3167808,"caller":"mlog/log.go:175","msg":"Action integration error","path":"/api/v4/posts/xxxxxxxxxxxxxxxxxxxx/actions/xxxxxxxxxxxxx","request_id":"mm4dfq9o6bxxxxxxxxxxx","ip_addr":"xxx.xxx.xxx.xxx","user_id":"xxxxxxxxxxxxx","method":"POST","err_where":"DoActionRequest","http_code":400,"err_details":"err=Post https://xxx.xxxx.xxx/plugins/com.github.moussetc.mattermost.plugin.giphy/shuffle: x509: certificate is not valid for any names, but wanted to match xxx.xxxx.xxx"}

@moussetc
Copy link
Owner

moussetc commented Mar 26, 2020

For those for which the AllowUntrustedInternalConnections solution did not work (thank you Jodacola!), please give (if you haven't already) :

  • the plugin version you're using
  • the Mattermost version you're using
  • the mattermost logs, not just the browser console network logs which are not detailed enough. The server logs are available in the System Console)
  • whether you've tried setting both localhost AND the domain name of your MM server in AllowUntrustedInternalConnections (don't forget to restart Mattermost).
  • information on your setup: are you running Mattermost on Docker? Are you using a self-signed SSL certificate? Is the self-signed certificate installed on the Mattermost Docker container?

I am unable to reproduce this issue with a local Docker 5.21 MM install without SSL, nor a manual 5.20 MM install with Let's Encrypt certificates.

@moussetc
Copy link
Owner

moussetc commented Apr 4, 2020

If you have Mattermost 5.20 or later, please try the new release of the plugin, with might fix the issue. If it doesn't, don't hesitate to comment back!

@jjtolton
Copy link
Author

jjtolton commented Apr 5, 2020

On a lower version of MM so can't install latest. Installed v1.1 of plugin and checked logs on error. Seeing this:

{"level":"error","ts":1586064487.7778633,"caller":"mlog/log.go:173","msg":"Action integration error","path":"/api/v4/posts/zrrtcwhfojfy8ptdr8kqu1tgdy/actions/ur7wmxy38pnnbm14ws1gd9d5eh","request_id":"ypxjczah4ffqbxyug7ophzazya","ip_addr":"**********","user_id":"zcgn9g3wfirwzciqcfnzsm9acy","method":"POST","err_where":"DoActionRequest","http_code":400,"err_details":"err=Post https://*************/plugins/com.github.moussetc.mattermost.plugin.giphy/send: x509: cannot validate certificate for ************ because it doesn't contain any IP SANs"}

This started happening after I rolled over MM SSL/TLS certs from certbot and forced all traffic to go through 443. Also I rewrite the ip address with the server name in NGINX like so:

    server {
    listen         80 default_server;
    server_name    *************;
    return         302 https://$server_name:443$request_uri;
}

proxy_cache_path /opt/bitnami/nginx/cache levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off;

server {
    listen 443 ssl;
    server_name    ***********;  

    ssl on;
    ssl_session_cache shared:SSL:10m;

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/****************/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/*****************/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    ...

Anyway ... I personally think the bitnami/GCP managed mattermost is total crap at this point. Nothing works the way it should. so I really doubt it's the plugin's fault. That being said if you have a lot of GCP users who use the managed bitnami, you might want to play around with it because the installation is nuts.

@jjtolton
Copy link
Author

jjtolton commented Apr 5, 2020

You can close this if you want, I'm not going to hold you to supporting MM v1.15. The way bitnami installed this thing makes it harder to upgrade than to just wipe it, migrate everything, and do a fresh server install.

@jjtolton
Copy link
Author

jjtolton commented Apr 5, 2020

okay gave it one more shot and I got it.

Did the following -- not sure which one of these ultimately did the trick:

Changed as follows:

server {
    listen         80 default_server;
    server_name    <domain-name> xx.yyy.zzz.aaa; 
    return         302 https://$server_name:443$request_uri;
}

proxy_cache_path /opt/bitnami/nginx/cache levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off;

server {
    listen 443 ssl;
    #old server name
    server_name    <domain-name> xx.yyy.zzz.aaa; 

(before it was just xx.yyy.zzz.aaa).

I also changed my config as follows:

{
    "ServiceSettings": {
        "SiteURL": "https://xx.yyy.zzz.aaa",
        "WebsocketURL": "",
... snip ...

to

{
    "ServiceSettings": {
        "SiteURL": "https://<domain-name>",
        "WebsocketURL": "",
... snip ...

This worked. However I can't say it was definitively this because I also did the following:

  • AllowUntrustedInternalConnections suggestion, but that had no effect.

  • I noticed I was encountering the error mentioned here:

https://docs.mattermost.com/administration/plugins.html#custom-plugins

regarding x509: certificate signed by unknown authority.

So I followed the steps as suggested here: https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list

to make the X509 go away. Buy I was still getting these:

{"level":"error","ts":1585258535.3829927,"caller":"mlog/log.go:173","msg":"Action integration error","path":"/api/v4/posts/9o1fg7msrjyiijh8ps4gektaqo/actions/kr7egecr4brefpk94ay3uyxh7c","request_id":"npm7h7zmxjyw3poxbrcnqiue4a","ip_addr":"**************","user_id":"b1kxfsukstyqmkx36o6ne7s8cy","method":"POST","err_where":"DoActionRequest","http_code":400,"err_details":"err=Post https://xx.yyy.zzz.aaa/plugins/com.github.moussetc.mattermost.plugin.giphy/send: x509: cannot validate certificate for xx.yyy.zzz.aaa because it doesn't contain any IP SANs"}

It was changing the config and the vhosts/mattermost.conf that finally did the trick.

So -- if I were to offer any suggestions -- check your logs. Look for apps/mattermost/server/logs/mattermost.log and tail them and then click on the plugin and see what you get. It might have something to do with either your SSL/TLS or possibly your domain name setup. Good luck!

@jjtolton jjtolton closed this as completed Apr 5, 2020
@jjtolton
Copy link
Author

jjtolton commented Apr 5, 2020

(also, I reverted to "AllowedUntrustedInternalConnections": "", and restarted, everything still works -- not sure if allowing localhost there would lower security or not but don't know what it does so changed it back)

@moussetc
Copy link
Owner

moussetc commented Apr 5, 2020

@jjtolton Congrats on solving the issue and thank you very much for sharing your solution! It might be quite useful to others :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants