Upload user avatars and store in attributes as URL instead of base64 encoded data

[drpetersen]

Background

There is an issue (#2631) ongoing about how to allow users to upload their own avatars. Basic functionality seems to work with the file prompt field (#3156) and the AUTHENTIK_AVATARS=attributes.avatar,… setting, but a few problems still remain to be solved.

While a file cropper seems nice to have, the show-stopper for me is having to store image files as base64-encoded strings directly in the user profile (attributes). Even with reasonably sized image files, this leads to performance issues (e.g., see #5942), makes it more cumbersome to edit the user profile in the admin interface (the YAML is hundreds of lines long), and may cause problems with proxying authentik-ated web applications (with avatars of ca. 100 KBytes, I received error 500 codes from nginx until I found out that I had to increase proxy buffers in size); even then, the /outpost.goauthentik.io/sign_out redirect for proxied applications errored out because query strings (presumably containing user profile data) became too long (I suppose).

My proposed solution is a workaround for this problem which allows the user to upload an image file as a user avatar, stores this image file in your authentik server's /media/ subdirectory under a random (non-guessable) file name, and stores the URL of this image file in the avatar profile attribute of the user.

This way, arbitrarily large image files (the maximum is configurable) can be used as a user avatar without cluttering the profile.

Credits: The helpful comments in issue #4283 as well as the above-mentioned issues pointed me in the right direction.

Procedure

• Include the attributes.avatar option in your AUTHENTIK_AVATARS environment variable (see here).

• Make sure the /media/ directory in your authentik-server container is writable by authentik and persistent. Avatar image files will be stored in a sub-directory /media/user-avatars/ (auto-created if not present).

• Create a custom File prompt, e.g., default-user-settings-field-avatar, with field key attributes.avatar; adjust the Order (not visible in the screenshot) as appropriate (e.g., 205)
  

• Create a custom checkbox prompt, e.g., default-user-settings-field-avatar-reset, with field key attributes.avatar_reset; adjust the Order (e.g., to 206). The user can check this box to delete the current avatar file.

• Create a custom expression policy, e.g., default-user-settings-avatar-authorization with this expression. This is where the uploaded file is saved, any previous file is removed, and the new URL is prepared to be stored in the user profile. Make sure to configure AK_DOMAIN, MAX_UPLOAD_SIZE and ACCEPTED_FILE_TYPES to your needs.

• Update your default-user-settings prompt stage (or a new, custom prompt stage, if you prefer) so that the default-user-settings-field-avatar and default-user-settings-field-avatar-reset prompts are included in the Fields selection (make sure not to accidentally unselect the default profile fields) and the default-user-settings-avatar-authorization is included in the Validation Policies (along with the stock default-user-settings-authorization policy).
  

• Done! Now your users should be able to customize their own avatar images. (Don't forget to re-create your docker container after updating environment options.)

Open Questions/Issues

• I am not sure if I am simply missing something, and this would have been possible with much less effort (at this time). And maybe there are more efficient ways to achieve this.
• I have not quite thought through the security implications of exposing the user avatar via a world-readable URL, protected only by its random name (a UUID). My intuition is that anyone who can see the avatar would also be allowed to know its URL, as they could copy the image file anyway, even if its download was protected. But maybe the name should be generated in a more cryptographically secure way, and/or the avatar URL should be behind authentik's access control.
• This solution relies on some Python packages being available in expression policies, which might not be the same in future authentik versions.
• The default-user-settings-avatar-authorization should catch and reject too large files, but there seems to be an implicit limit where things start to go wrong. Specifically, I had problems with large (but still reasonably sized) files: After uploading a files of 1 – 2 MB, I get no error message, but the UI switches from direct display of profile fields to a button "Open settings", which then opens the profile on a separate page, and when I hit the "Continue" button, the upload seems to have failed (silently). I don't know where to begin debugging this. -- EDIT: This is solved, I forgot to increase the client_max_body_size setting in my nginx reverse proxy. 🙄
• Finally, I was not sure if this is the right place to put this. Issue Custom avatar pictures #2631 seems to be headed in a different direction, issue File Prompt Placeholder Not Working #4283 had already been closed. So, I put this here in the hope that someone might find it helpful. 😄

[thefeli73]

for me it did not in fact autocreate the user-avatars/ folder, i had to create it manually for this to work. Great guide otherwise :D

[Elara6331]

Thank you so much for this, it works very well! I just had to add the following if statement to the beginning of remove_old_avatar_file() to make this policy work during enrollment when there is no existing user yet:

if not request.user.is_authenticated:
  return

[dasunsrule32]

This works for normal usage, but when impersonation is used, it breaks things pretty badly.

[Aetherinox]

This guide works great. Only thing to note is as @thefeli73 said, the user-avatars folder is not automatically created and if you attempt to upload an avatar, it'll throw an error until you create the folder and assign proper perms / owner.

mkdir -p /authentik/media/user-avatars/
chown -R 1000:1000 /authentik/media/user-avatars/
chmod -R 644 /authentik/media/user-avatars/

Obviously adjust chown owner to whatever you need. I got the avatar upload to work with permission 644

And if you have multiple sources for avatars, stick the custom upload to the front, otherwise initials will have priority. Mine didn't work until I flipped the order.

attributes.avatar,gravatar,initials