mattermost-mobile: Profile picture doesn't show if SSO

Summary

profile picture doesn’t show when SSO.

Environment Information

  • Device Name: iOS simulator
  • OS Version: 13.2.2
  • Mattermost App Version: 1.32.0
  • Mattermost Server Version: 5.21.0

Steps to reproduce

  1. sso login (gitlab)
  2. and then check profile picture

Expected behavior

show profile picture

Observed behavior

the http request:

GET https://mm.test.domain/mm/api/v4/users/67um3oztnp8n8yexu1wdkjju7c/image HTTP/1.1
Host: mm.test.domain
Accept: image/*,*/*;q=0.8
Accept-Language: en-us
Connection: keep-alive
Accept-Encoding: gzip, deflate, br
User-Agent: Mattermost/1.32.0 (iPhone; iOS 13.2.2; Scale/2.00)

response:

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Expires: 0
Vary: Accept-Encoding
X-Request-Id: hhzpbu8617ropcu351nb4zwefo
X-Version-Id: 5.21.0.5.21.0.d034a3d0686bcd932fa7681706e0c3f1.false
X-Powered-By: ARR/3.0
X-Powered-By: ASP.NET
Date: Fri, 26 Jun 2020 08:19:39 GMT
Content-Length: 186

{"id":"api.context.session_expired.app_error","message":"Invalid or expired session, please login again.","detailed_error":"","request_id":"hhzpbu8617ropcu351nb4zwefo","status_code":401}

Possible fixes

go to app\components\profile_picture\profile_picture.js change:

source = {
                uri: `${prefix}${pictureUrl}`,
            };

to

source = {
                uri: `${prefix}${pictureUrl}`,
                headers: {Authorization: `BEARER ${Client4.token}`},
            };

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 45 (18 by maintainers)

Most upvoted comments

@svenseeberg, as I explain above, the main problem, the mobile app, used WebView & RNFetchBlob for communicate with server, thus the cookie(MMAUTHTOKEN) is stored in different location.
(which doesn’t have this issue for browser) we just “copy the cookies to NSHTTPCookieStorage.sharedHTTPCookieStorage” after sso login, that resolve the issue for our case. we didn’t change anything at server side.

as @enahum said “as soon as the first response gets in, the cookies in that response are being set, which includes MMAUTHTOKEN”. unluckily, in our server, which doesn’t set that cookie for that response. I haven’t have chance to review the server side yet.

Closing as a Help Wanted issue was opened for this https://github.com/mattermost/mattermost/issues/25353.

@svenseeberg Sadly nothing relevant seems to appear on the logs 😦 .

If necessary, I can fire up mitmproxy again to capture the Authorization headers and compare with the web app.

Seeing the traffic would help a lot, yes. Mainly to make sure the proper calls are being made, and they properly resolve. If you are willing to do it, please let us know the results. Thank you!

Also, if you could share the logs of the app it would be great (Profile -> Settings -> Report a Problem). You can share them with me privately by DM on our community server: https://community.mattermost.com/private-core/messages/@daniel.espino-garcia

Or if you don’t feel comfortable for any reason sharing the logs with me, it would be great at least if you could take a look to the logs to see if there is any relevant error on them.

Latest from the store, preferably beta.

@svenseeberg Is it possible to try with the official android version? I understand the reasons to use F-Droid, but it is not officially maintained by us (it is maintained by the community), and I want to discard any potential difference between the two before digging deeper into the issue.

If testing with the official android version, let me know, and I will see what we can do 😃

it looks like the affected deployments are not many in comparison with the amount of deployments that use SSO, which leads me to believe this is not really about the app but perhaps something in a reverse proxy or something.

I agree that this sounds likely. However, we already compared our configuration multiple times with the documentation and could not find any issues. We are using Gitea as an IdP instead of Gitlab. I was not yet able to determine if or why this would make a difference.

@svenseeberg @enahum

Just wanted to add some extra data to the issue. We are a corporate customer, on Enterprise Cloud. This affects us too. There’s nothing I can do about our server config or reverse proxies, because that’s all configured at MM. On my own iPad (company managed) I was having the same problem, and I logging out/in didn’t work. But removing the app, then reinstalling and logging in worked. That must be enough to clear out any problematic caches.

I’m glad it works, but I’m wondering if there is a path forward knowing this? We’re bound to have more issues with this (even if in a small fraction of users). Thanks for all your hard work!

@anurag6713 can you take a look into this?