Avatars not pulling from SSO

I’m using Moodle as an SSO identity provider on 2.2.0beta7, and it all seems to be working fine except user avatars aren’t updating.

I’ve got sso overrides avatar set to true, and I’ve got avatar_force_update returning true from the payload. The verbose debugging log gives the following output:

Verbose SSO log: User was logged on peter

add_groups: 
admin: 
moderator: 
avatar_force_update: true
avatar_url: https://moodle.***.***/pluginfile.php/42/user/icon/fordson/f1?rev=490
bio: 
card_background_url: 
email: peter@***.***
external_id: 4
groups: 
locale: 
locale_force_update: 
name: Peter *****
nonce: 66905e176b65dfde1eacc9edd5ada50f
profile_background_url: 
remove_groups: 
require_activation: 
return_sso_url: 
suppress_welcome_message: 
title: 
username: peter@***.***
website: 

I’ve gone through all the other threads on here, but none of the suggestions seem to work. Enqueuing the download_avatar_from_url function from the rails console seems to give no error, and there’s absolutely nothing showing up in my logs aside from the verbose sso output. New users show up with the default capital letter avatar, and returning users just keep whatever they had before.

Any tips on how I might further debug would be greatly appreciated.

The obvious answer is that this is a problem on the SSO provider side, but at least as far as I understand from the verbose SSO log, the proper information is coming back. Any other tips on how I might troubleshoot this?

2 Likes

If you go to settings, search for sso, there is this setting. Have you enabled it?

image

It’s enabled, unfortunately. I’ve played with just about every combination I can think of on those settings, but no joy.

Ah… Then I bet we struggle with the same issue, i dont use the avatar thing, but I struggle with getting the admin / moderator / groups info accounted for instead.

1 Like

Are you 100% certain that the avatar url you provided is something the Discourse container can talk to?

We have tests for this function: https://github.com/discourse/discourse/blob/76669bb5a6dfa8c3425c1988ae7f240f23fd28cf/spec/models/discourse_single_sign_on_spec.rb#L523-L550

2 Likes

That’s definitely a possibility, and one I’m trying to investigate. I’m wondering if it could be that my cms is serving different things to different clients based on…something. I’m not especially familiar with the moodle backend, but if it’s something to do with that I’ll post a solution here when I find it.

If you throw the avatar url at cURL or wget can you download the asset?

Yes, without problem. That’s what’s so strange.

Have you checked to make sure that sidekiq is running properly? I just found out there were some jobs holding things up in the queue and our images are back to normal after fixing that.

3 Likes

Just to update: no surprise, it looks like the issue is on the moodle end, related to an authentication edge case in the filesystem API. I don’t completely understand it yet, but by changing some settings related to Moodle’s authentication process I am now able to load avatar images appropriately.

I’m not sure why pulling the image via curl worked consistently before, but when I checked again after letting it sit for a few weeks I stopped getting anything. My only guess is that maybe someone upstream from me has some bad caching configured.

Anyway, a sincere thanks to everyone for the help. Things are working great now, and my users are absolutely loving discourse. If I figure out anything more specific, I’ll post it here.

2 Likes