Implement LDAP avatar serving #1

Merged

informatic merged 1 commits from q3k/avatar-serve into master

2023-10-08 18:19:22 +00:00

q3k commented

2023-10-08 16:19:26 +00:00

Owner

This adds a /avatar/ endpoint which serves any jpegPhoto associated
with a given user account.

In true 'lol ldap' fashion, only photo and jpegPhoto fields are
defined. The first one is for G3 photos (a fax format!). The latter is
technically for JPEG. But we expect to abuse this and basically contain
any sensible photo format in there, as long as Python's PIL can parse
it.

The serving function always resamples images to a 256x256 PNG. This
makes sure people don't leak EXIF and lets us depend on square avatars.

This entire code assumes that it is safe to PIL.Image.open untrusted
user data. My understanding is that it is, bar some DoS for very large
images. We limit the potential for DoS by storing the images in LDAP,
which I hope has some kind of field length limit...

Oh, and this also adds a 'default avatar' functionality which serves
simple generative mermaid art for any user who doesn't have an explicit
avatar set. To prevent leaking the existence of users who don't have an
avatar set, we serve such a generated avatar for all UIDs, including
UIDs which don't exist.

This adds a /avatar/<uid> endpoint which serves any jpegPhoto associated with a given user account. In true 'lol ldap' fashion, only `photo` and `jpegPhoto` fields are defined. The first one is for G3 photos (a fax format!). The latter is technically for JPEG. But we expect to abuse this and basically contain _any_ sensible photo format in there, as long as Python's PIL can parse it. The serving function always resamples images to a 256x256 PNG. This makes sure people don't leak EXIF and lets us depend on square avatars. This entire code assumes that it is safe to PIL.Image.open untrusted user data. My understanding is that it is, bar some DoS for very large images. We limit the potential for DoS by storing the images in LDAP, which I hope has some kind of field length limit... Oh, and this also adds a 'default avatar' functionality which serves simple generative mermaid art for any user who doesn't have an explicit avatar set. To prevent leaking the existence of users who don't have an avatar set, we serve such a generated avatar for all UIDs, including UIDs which don't exist.

informatic was assigned by q3k

2023-10-08 16:19:26 +00:00

q3k added 1 commit 2023-10-08 16:19:26 +00:00

a435e15698 Implement LDAP avatar serving

This adds a /avatar/<uid> endpoint which serves any jpegPhoto associated
with a given user account.

In true 'lol ldap' fashion, only `photo` and `jpegPhoto` fields are
defined. The first one is for G3 photos (a fax format!). The latter is
technically for JPEG. But we expect to abuse this and basically contain
_any_ sensible photo format in there, as long as Python's PIL can parse
it.

The serving function always resamples images to a 256x256 PNG. This
makes sure people don't leak EXIF and lets us depend on square avatars.

This entire code assumes that it is safe to PIL.Image.open untrusted
user data. My understanding is that it is, bar some DoS for very large
images. We limit the potential for DoS by storing the images in LDAP,
which I hope has some kind of field length limit...

Oh, and this also adds a 'default avatar' functionality which serves
simple generative mermaid art for any user who doesn't have an explicit
avatar set. To prevent leaking the existence of users who don't have an
avatar set, we serve such a generated avatar for all UIDs, including
UIDs which don't exist.

informatic merged commit a435e15698 into master

2023-10-08 18:19:22 +00:00

informatic deleted branch q3k/avatar-serve

2023-10-08 18:19:23 +00:00

No reviewers

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hswaw/ldapweb#1

There is no content yet.