I'm not sure where we found the information for it being generally stored as base64 string, but I just found out that Gitea only supports the binary format, and the RFC for inetOrgPerson also doesn't mention encoded strings.
Since I only just deployed the version with base64 today, I'll change it asap so we don't announce before it works with Gitea and ejabberd at least.
I'm not sure where we found the information for it being generally stored as base64 string, but I just found out that Gitea only supports the binary format, and the [RFC for inetOrgPerson](https://www.rfc-editor.org/rfc/rfc2798#section-2.6) also doesn't mention encoded strings.
Since I only just deployed the version with base64 today, I'll change it asap so we don't announce before it works with Gitea and ejabberd at least.
raucao
self-assigned this 2024-01-22 10:58:55 +00:00
raucao
changed title from Switch LDAP avatar to store raw JPEG/PNG instead of base64-encoded string to Switch LDAP avatar to store raw JPEG instead of base64-encoded string2024-01-22 10:59:14 +00:00
I have a working implementation of this in 9e2210c now, but now I'm not sure it makes sense anymore. There are a few issues with the idea of storing this in LDAP in general, which I'll document here for posterity:
If we're strict about it, the file type would have to be a JPEG, which means when converting it, we lose e.g. PNG transparency for images that use it.
We can't store multiple versions (e.g. sizes) this way
A public HTTP endpoint would rely on LDAP as backing file store, but it would be more efficient and robust to just use our public S3 endpoints directly (which also have proxy caching built in already)
Not all services are able to use the avatar from LDAP directly, so if we want to have options for updating an avatar for multiple services, we need to store it in other places anyway. And we should probably make it possible to not overwrite all avatars in all places via UI options
I'm not sure how widely supported this is, but for XMPP, the protocol makes it possible to also use HTTP URIs instead of image data when publishing avatar updates to PEP
So, considering all these points, I think it makes more sense to just use ActiveStorage to store avatars in S3/Garage (or filesystem for smaller akkounts deployments), and then have multiple jobs to update them in services where needed or desired. One of them can be the LDAP one that from abovementioned commit, so it's possible to use it from there also.
I have a working implementation of this in 9e2210c now, but now I'm not sure it makes sense anymore. There are a few issues with the idea of storing this in LDAP in general, which I'll document here for posterity:
* If we're strict about it, the file type would have to be a JPEG, which means when converting it, we lose e.g. PNG transparency for images that use it.
* We can't store multiple versions (e.g. sizes) this way
* A public HTTP endpoint would rely on LDAP as backing file store, but it would be more efficient and robust to just use our public S3 endpoints directly (which also have proxy caching built in already)
* Not all services are able to use the avatar from LDAP directly, so if we want to have options for updating an avatar for multiple services, we need to store it in other places anyway. And we should probably make it possible to not overwrite all avatars in all places via UI options
* I'm not sure how widely supported this is, but for XMPP, [the protocol](https://xmpp.org/extensions/xep-0084.html#examples) makes it possible to also use HTTP URIs instead of image data when publishing avatar updates to PEP
So, considering all these points, I think it makes more sense to just use ActiveStorage to store avatars in S3/Garage (or filesystem for smaller akkounts deployments), and then have multiple jobs to update them in services where needed or desired. One of them can be the LDAP one that from abovementioned commit, so it's possible to use it from there also.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I'm not sure where we found the information for it being generally stored as base64 string, but I just found out that Gitea only supports the binary format, and the RFC for inetOrgPerson also doesn't mention encoded strings.
Since I only just deployed the version with base64 today, I'll change it asap so we don't announce before it works with Gitea and ejabberd at least.
Switch LDAP avatar to store raw JPEG/PNG instead of base64-encoded stringto Switch LDAP avatar to store raw JPEG instead of base64-encoded stringThis one turns out to be more difficult than I expected. Could use another set of eyes to look at what I have, which isn't working as it should...
I have temporarily hidden the feature by default, so we don't have to care about migrating existing avatars at some point.
I have a working implementation of this in
9e2210cnow, but now I'm not sure it makes sense anymore. There are a few issues with the idea of storing this in LDAP in general, which I'll document here for posterity:So, considering all these points, I think it makes more sense to just use ActiveStorage to store avatars in S3/Garage (or filesystem for smaller akkounts deployments), and then have multiple jobs to update them in services where needed or desired. One of them can be the LDAP one that from abovementioned commit, so it's possible to use it from there also.