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

Unable to add attribute: users and team names are not recognized #63

Open
gabrielctn opened this issue Feb 26, 2021 · 6 comments
Open

Comments

@gabrielctn
Copy link

gabrielctn commented Feb 26, 2021

Hi,
I am unable to add a custom attribute.
I want to set the team name, but it is not recognized (it is registered as DSIMB in mattermost), neither are usernames (I tried with and without "@").

image

Here are versions infos (I installed mattermost via docker-compose):

root@www:~# docker exec -it b0fde455f218 mattermost version
Version: 5.30.0
Build Number: 5.30.0
Build Date: Fri Dec 18 06:52:48 UTC 2020
Build Hash: 25659c5b436aac171aedbee39ded4bc2ffac9838
Build Enterprise Ready: true
DB Version: 5.31.0

(I have Mattermost EE, without license key, the edition is not activated)

@gabrielctn gabrielctn changed the title Users and team names are not recognized Unable to add attribute: users and team names are not recognized Feb 26, 2021
@zaengerlein
Copy link

zaengerlein commented Mar 22, 2022

I just installed the Custom Attributes plugin on our server and we experience the same issue. Neither user nor team search return any results.
This is a major issue, as it renders the plugin unusable as far as I can see?
When inspecting the request & response which entering text in the username / teamname text boxes triggers, I found that the server for some reason responds with a HTTP 400 error response. Here are the detail, I hope they help debugging. Can I do something more to expedite to find out whether this is some error specific to our installation or whether this is an issue in either the API request triggered by the plugin?

`Request
POST /api/v4/users/search
Content-Type: text/plain;charset=UTF-8
Accept: /
Origin: https://OURSERVERURL
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15
X-Requested-With: XMLHttpRequest
X-CSRF-Token: h1wqofmzf38r9cbxydpywpjmyw

Redirect Response
302 Found
Date: Tue, 22 Mar 2022 14:47:52 GMT
Location: /mattermost/api/v4/users/search

Request
GET /mattermost/api/v4/users/search HTTP/1.1
Accept: /
Origin: https://OURSERVERURL
Cookie: MMAUTHTOKEN=THETOKEN; MMCSRF=h1wqofmzf38r9cbxydpywpjmyw; MMUSERID=9r8oheaa5ibb9butu8qqa979sw; rl_anonymous_id=RudderEncrypt%3AU2FsdGVkX183UBkrtKmI3qkPaFtwivpS%2F5yKCxyhDkJNVlriTaCufHdTzyHl2mV3UHP0ZQewOjRiY0ysmlq1UQ%3D%3D; rl_trait=RudderEncrypt%3AU2FsdGVkX19OcwZNp4l24B4A9Jq6VUB9J5eEbjlJ2Is%3D; rl_user_id=RudderEncrypt%3AU2FsdGVkX1%2BjsqD6yqPDWvEhvKRoPT44qfXLR20Ot94BLON8RMFabpcN%2FBUjwrbT; _ga=GA1.2.604029463.1647867422; rl_page_init_referrer=RudderEncrypt%3AU2FsdGVkX19jTC69QubWsfUytUK33w9ij9MGA4e3b2E%3D; rl_page_init_referring_domain=RudderEncrypt%3AU2FsdGVkX1%2BqkxbklpU0mblBOMyvmuGsEFalLJa6Bkw%3D
Host: ...
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15
Accept-Language: de-DE,de;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
X-CSRF-Token: h1wqofmzf38r9cbxydpywpjmyw
X-Requested-With: XMLHttpRequest

Response
HTTP/1.1 400 Bad Request
Content-Type: application/json
Vary: Accept-Encoding
Date: Tue, 22 Mar 2022 14:47:52 GMT
Content-Length: 201
Expires: 0
Connection: close
Server: Apache/2.4.41 (Ubuntu)
X-Version-Id: 6.3.3.6.3.3.8b47315f7db8caeee0fdce3efe04cdef.false
X-Request-Id: z7ktprr6wfb3tfe3rergy5c9sh`

The get request contains the following request data (which I think looks fine) and no mime-type is set.
{"term":"a"}

When I compare this request to the request data which is sent for a successful user search request, I see that there a mime-type is set for the request: "application/json".

The server log shows the following entry when entering text in the respective text boxes:
{"timestamp":"2022-03-22 15:55:33.438 +01:00","level":"debug","msg":"Invalid or missing user_id parameter in request URL.","caller":"web/context.go:101","path":"/mattermost/api/v4/users/search","request_id":"miamw44uf3rdtc5t1oqu37x7th","ip_addr":"127.0.0.1","user_id":"9r8oheaa5ibb9butu8qqa979sw","method":"GET","err_where":"Context","http_code":400,"err_details":""}

@gabrielctn
Copy link
Author

If it can help, I personally figured that after managing to migrate to a subdomain URL instead of subpath installation, the plugin worked:
https://mattermost.example.com instead of https://example.com/mattermost
It is annoying because Mattermost (almost) support subpath installation, but I had many more issues (with Boards just to mention it for example).
I would recommand, if you can, to use a subdomain installation.

@zaengerlein
Copy link

@gabrielctn thanks for your suggestion, this is highly appreciated. We are already using a subdomain installation for our server but apparently combined with a subpath 🧐 I will test your suggestion.
Can I just remove the subpath from the server URL in the configuration and restart? I suppose this will result in errors for all users currently logged in... 🙈

@gabrielctn
Copy link
Author

You are most welcome !
Yes it is that simple, in the config.json file, just set the line "SiteURL": "https://mattermost.yoursite.com", restart and voilà.
At least, it worked for me 😉
Of course users will have to set the modified URL in their Mattermost App server settings, and most probably do the famous "Clear Cache and Reload".

@zaengerlein
Copy link

@gabrielctn I am flabbergasted! Removing the subpath in the SiteURL did indeed resolve the issue for me as well! Again thank you! I hope your tip also helps the Mattermost team to fix the issue :)

@muratbayan
Copy link

muratbayan commented Jul 11, 2023

This issue is there on v1.3.1, could a fix be considered? Multiple organizations I work with tend to run proof of concept or small deployments using subpaths, some of which remain under a subpath for the long term, some moving to a subdomain over time

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

3 participants