Avatars not loading (GitHub Enterprise Integration)

Hi there, I have setup Drone to use an enterprise version of GitHub. Everything has been working fantastic, except the avatars do not load.

Here is the drone-server section of my docker-compose.yaml file,

  server:
    image: drone/drone:1
    environment:
    - DRONE_AGENTS_ENABLED=true
    - DRONE_DATABASE_SECRET={{ drone_database_secret }}
    #- DRONE_GIT_ALWAYS_AUTH=true
    - DRONE_GITHUB_CLIENT_ID={{ git_client_id }}
    - DRONE_GITHUB_CLIENT_SECRET={{ git_client_secret }}
    - DRONE_GITHUB_SERVER={{ git_server }}
    - DRONE_LOGS_COLOR=true
    - DRONE_LOGS_DEBUG={{ env_debug }}
    - DRONE_LOGS_PRETTY=true
    - DRONE_LOGS_TEXT=true
    - DRONE_LOGS_TRACE={{ env_debug }}
    - DRONE_REPOSITORY_FILTER={{ git_owner }}
    - DRONE_RPC_SECRET={{ drone_runner_secret }}
    - DRONE_SERVER_HOST={{ proxy_drone_url }}
    - DRONE_SERVER_PROTO=https
    - DRONE_USER_CREATE=username:{{ drone_username }},machine:false,admin:true,token:{{ drone_token }}
    - DRONE_ADMISSION_PLUGIN_ENDPOINT=http://drone_administration:3000
    - DRONE_ADMISSION_PLUGIN_SECRET={{ secret }}
    deploy:
      replicas: 1
      update_config:
        parallelism: 1
      restart_policy:
        condition: on-failure
      labels:
      - traefik.docker.network={{ docker_network }}
      - traefik.enable=true
      - traefik.frontend.priority=5
      - traefik.frontend.rule=Host:{{ proxy_drone_url }}
      - traefik.frontend.whiteList.useXForwardedFor=true
      - traefik.port=80
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - {{ directories_drone_data }}:/data
    - /etc/ssl/certs/:/etc/ssl/certs/
    - /etc/localtime:/etc/localtime
    networks:
    - drone_net

Based on inspecting the network request that Chrome is handling for the avatar, the request is going to a login redirect instead of loading the image.

It is loading something like this: Initiating SAML single sign-on

Can you help? Not sure what I am doing wrong.

Thanks – love this tool.

Hey there, the avatar urls are sourced from the GitHub API [1] and GitHub webhooks

It sounds like GitHub Enterprise is returning the http url instead of the https url. We see this sometimes when our users install Gitea (a self-hosted GitHub clone). They are usually able to resolve this by updating the BASE_URL setting in Gitea, which tells Gitea its correct url … I am not sure what the equivalent setting is in GitHub enterprise, but I presume they have something similar. Hopefully that helps :slight_smile:

[1] Users - GitHub Docs

Wow, thanks for the speedy response!

So, in order to verify what you are suggesting, I use the Chrome Dev Tools to inspect the Avatar element, and per the screenshot (I replaced my company name obviously, but nothing else) it looks like the correct url for the avatar is there. Infact, I pasted that URL into my browser and it correctly pulled up an avatar. So, I can’t figure out why Drone can’t seem to display it.

What are your thoughts @bradrydzewski?

what happens if your curl the avatar url from the command line? does the response indicate a redirect is being returned from GHE? I have never seen this before, to be honest, but perhaps your GHE instance is configured to require login to view avatars?

Ah, you are onto something.

$ curl https://scm.mycompany.com/avatars/u/1506
<html>
   <body>
      You are being <a href="https://scm.mycompany.com/login?return_to=https%3A%2F%2Fscm.mycompany.com%2Favatars%2Fu%2F1506">redirected</a>.
   </body>
</html>

So, I take it that avatars normally do not require auth? So, I should touch base with the GHE team and see if they can adjust things for me?

So, I take it that avatars normally do not require auth? So, I should touch base with the GHE team and see if they can adjust things for me?

correct, I have never seen this behavior before, so I would check with your team that managed GHE and see if there is a setting that can be adjusted :slight_smile:

Okay, will do. Thanks a lot!

So, I touched base with our GHE team and they reached out to GitHub support who said that this is a known limitation of GHE.

Here is the email correspondence for more details.

hmm … I have to be honest that I am a bit surprised by their response. We have ~500 organizations using Drone with Github Enterprise and this has never been reported. I also used Drone with Github Enterprise and did not experience any issues with avatars, albeit this was back in 2015. I am going to reach out to one of our customers that is using GHE + SAML to see if they are experiencing issues with avatars.

1 Like

I am facing the same issue. The browser is not loading those images complaining them to be CORB
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://github.enterprise/login?return_to=https%3A%2F%2Fgithub.enterprise%2Favatars%2Fu%2F65149%3F with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.

This happened to me too due to the avatar URL requiring some enterprise oauth flow which creates some redirects before I can reach the image.

I noticed it only happens in Chrome; Firefox and Safari (mobile) are fine.

I don’t know why but Chrome seems to not follow the redirect.

Yeah, I’m seeing the exact same thing here. Inspecting the element in Drone shows <my-ghe-domain>/avatars/u/<uid>?. Opening this in a browser loads it fine - if I’m logged into GHE. curling it also gives me a redirect response (presumably, it’s redirecting to the login page.

I believe we have GHE connected to LDAP for authentication. Maybe this issue depends on what authentication provider is being used for GHE?

We just published a preview release of Drone 2.0 (Drone 2.0 available for testing) and we added fallback to display your initials if we cannot load the avatar. I know this isn’t a perfect solution, but much better than the “broken image” icon.

I am going to ask one of our developers to go through and make sure we have wired this up everywhere in the application. It may not be wired up on every page yet, but if not, we can have resolved in the next few days.

2 Likes

FYI, we’ve run into the same issue at Reviewable. I believe it has to do with GHE being set to run in private mode and recent changes to SameSite defaults for cookies (which is why behavior can vary by browser). I’m not aware of any good workarounds. Our analysis is here FWIW: Avatar images are broken on GHE Server running in private mode · Issue #770 · Reviewable/Reviewable · GitHub.