OIDC warning: Failed to get user avatar from URL

Help / Discuss
1

Hi.

I often see warnings from oidc I think in our logfile:

2026-03-11 14:57:36,730 [https-jsse-nio-8443-exec-1 - https://example.org/oidc/authenticator/callback?code=SNIP&session_state=SNIP] WARN  o.x.c.o.a.i.OIDCUserManager    - Failed to get user avatar from URL [https://graph.microsoft.com/v1.0/me/photo/$value]: FileNotFoundException: https://graph.microsoft.com/v1.0/me/photo/$value

Our config looks like this:

oidc.endpoint.authorization=https://login.microsoftonline.com/SNIP/oauth2/v2.0/authorize
oidc.endpoint.logout=https://login.microsoftonline.com/SNIP/oauth2/v2.0/logout
oidc.endpoint.token=https://login.microsoftonline.com/SNIP/oauth2/v2.0/token
oidc.endpoint.token.auth_method=client_secret_post
oidc.endpoint.userinfo=https://graph.microsoft.com/oidc/userinfo
oidc.endpoint.userinfo.method=POST
oidc.logoutMechanism=rpInitiated
oidc.scope=openid
oidc.clientid=SNIP
oidc.secret=SNIP
oidc.user.nameFormater=${oidc.user.givenName._clean}${oidc.user.familyName._clean}
oidc.groups.claim=groups
oidc.userinfoclaims=groups

Someone an idea how to avoid this?

Regards, Simpel

2

Some steps further. I found this in the oidc code:

// Avatar
        if (userInfo.getPicture() != null) {
            try {
                String filename = FilenameUtils.getName(userInfo.getPicture().toString());
                URLConnection connection = userInfo.getPicture().toURL().openConnection();
                if (accessToken != null) {
                    connection.setRequestProperty("Authorization", accessToken.toAuthorizationHeader());
                }
                connection.setRequestProperty("User-Agent", this.getClass().getPackage().getImplementationTitle() + '/'
                    + this.getClass().getPackage().getImplementationVersion());

                try (InputStream content = connection.getInputStream()) {
                    // Get the maximum attachment size
                    int filenameSizeLimit =
                        xcontext.getWiki().getStore().getLimitSize(xcontext, XWikiAttachment.class, "filename");
                    if (filename.length() > filenameSizeLimit) {
                        // If the provided file name is too long, use an arbitrary one
                        filename = "oidc-avatar";
                        String ext = FilenameUtils.getExtension(filename);
                        if (ext.length() < 10) {
                            filename += '.' + ext;
                        }
                    }

                    // Update the attachment content
                    XWikiAttachment attachment = modifiableDocument.setAttachment(filename, content, xcontext);

                    // Calculate the attachment mime type
                    attachment.resetMimeType(xcontext);
                }
                userObject.set("avatar", filename, xcontext);
            } catch (IOException e) {
                this.logger.warn("Failed to get user avatar from URL [{}]: {}", userInfo.getPicture(),
                    ExceptionUtils.getRootCauseMessage(e));
            }

So I guess if a user doesn’t have an avatar microsoft returns 404 and so it raises a warning?

I will set logging for “org.xwiki.contrib.oidc.auth.internal.OIDCUserManager” on “ERROR” for a quick win. But that’s not my favorite solution. Maybe the exception for a missing avatar could be a debug instead warn in the future?

3

To me the problem is more that microsoft should not give a URL (one that seems broken by the way) to download the avatar if the user does not have an avatar in the first place…

But honestly I’m not sure why a warning was used here, and a debug log would be more consistent with authenticators tradition. Would be great if you could create a jira issue about that.

4

Done with Loading....

5

This quick fix will not survive a wiki restart. How can I make it more persistent?

6

You can edit the logback.xml file and add a new entry. See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Logging.

7

Unfortunately I can’t edit files in the backend.

8

Fixed and released (2.20.2).

1 Like
9

Wow. That was very fast. It works.

Thanks, Simpel

10

To be fair, that was an easy Bug Fixing Day “point” :slight_smile:

11

So it was the right time to ask for. Perfect.