SSO avatar sync not working due to incorrect HTTP HEAD response


(Dany) #1

My main website is connected to my discourse application with SSO activated. Evrything work fine but the avatar syncing between website discourse.

I read all the thread about this and didn’t find any solution. I have configured “sso overrides avatar” and set avatar_force_update to true.

Here is the weired thing. First of all both my website and discourse are public with public ip / DNS etc not on localhost dev.

When the avatar url is hosted on any other website then mine then the avatar is uploaded / synced without any problem. So my integration code (SSO) is working.

When the avatar url is sent from my own website even if it is the same image that worked just before on another host then the sync just don’t work and the avatar don’t change.

So i think there is something special with my host (Nginx). Maybe the nginx gzip http reponse or something else ? I spend already 4 days trying to find an explanation without success and without any error message in avatar logs with sso logs activated that’s why i am here now.

The only Thread i found which seems to have the same problem is : Cannot load avatar images from particular sites but without any solution.

Any help would be apreciated.

Thanks !


(Jeff Atwood) #2

Any ideas here @sam or @tgxworld? Things to look for?


(Alan Tan) #3

Anything in /logs? Our URL resolver has had problems recently downloading from certain URLs.


(Dany) #4

There is not any exceptions / error in logs files. If needed i can send you an avatar URL in private in order to let you test.
You just have to force my avatar url in your SSO and voilà !


(Alan Tan) #5

Sure can you PM me the URL so that I can test it out?


Cannot load avatar images from particular sites
(Alan Tan) #6

Hmm this is odd, nginx on your site throws 404 when responding to a HEAD request.

$ curl --head <url>
HTTP/1.1 404 Not Found
Server: nginx/1.12.0
Date: Thu, 30 Nov 2017 04:44:41 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 9
Connection: keep-alive
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT

(Dany) #7

Yeah i didn’t implemented the HEAD http method because i don’t need it. Is this the cause of the bug ? If yes then why do you make a head request before getting the image because the head is already send with GET.


(Dany) #8

Ok i patched my code to answer to HEAD request and now it is working.
You should mention that somewhere in the SSO doc :sweat:. You can’t imagine how many thread i found having problem with discourse SSO avatars.

Thanks for your help :+1:


Cannot load avatar images from particular sites
(Richard - DiscourseHosting.com) #9

Just checking: so you didn’t implement an important part of the HTTP specification and you think it’s the fault of the documentation of another system?


(Sam Saffron) #10

Note for future ref, the correct way of not implementing HEAD is by returning a 405 Method Not Allowed


(Dany) #11

I opened an issue on the framework i use in order to get more info about the default framework answer for non existing HTTP request.

I am, like most of web developpers, using a web framework. My web framework let me define each HTTP method separatly. Listening to you for each GET request i should implement his HEAD request equivalent ? (i am not making irony here it is a real question…)

@RGJ maybe you are right about the fact that “i didn’t implement an important part of the HTTP specification”. But i still think this should be mentionned somewhere in the doc or at least throw an error. Discourse SSO can’t make a “hidden head request” get an error and not write anything in logs.


(Richard - DiscourseHosting.com) #12

I have never seen a modern framework which does not handle HEAD requests transparently as soon as you define a GET request… Which framework are you using?

The idea behind a protocol specification is that docs are not cluttered with all kinds of details. Deviations of the specification should be mentioned, but it’s impossible to document where something relies on the specification. If your framework indeed does not handle HEAD requests, then that would be the place where it should be documented.

I do agree with you that throwing or logging an error would have been very helpful.


(Jeff Atwood) #13

Why would you even disable HTTP HEAD? This is pointless. All you did is create extra work for yourself, and for us in replying to you.


(Dany) #14

@RGJ i am using a java framework called ninjaframework. I agree with you about everything dude i just never used HEAD request before because i never had to use it yet. My framework handle HEAD request but not automatically that’s the problem and many other framework doesn’t neither. But still, an error in logs should be welcome and as i told you i am not the only one facing this problem.

@codinghorror i didn’t disabled it, i just didn’t implemented it and the framework i use don’t do it automatically. Actually the only solution i get is that for each GET request i should clone it to HEAD request equivalent and spam my routing file with Head equivalent for all my GET methods. And that’s really ugly. I just did it for my assets folder in order to making avatar syncing work. I also don’t consider all this talking being a wast of time. This will help many people to do things the right way.

I also opened an issue and you guys are welcome : HTTP head philosophy · Issue #592 · ninjaframework/ninja · GitHub


(Jeff Atwood) #15