Accept and display profile images of any format. #135
No reviewers
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
KittenSquad/glewlwyd!135
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "accept-only-jpeg"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
glewlwyd currently accepts only profile images of a single hard-wired format (JPEG by default). Uploading a different file format results in an invalid Base64 URI. Although it should be possible to detect the image type and adjust the Base64 URI accordingly, in this PR I am opting for the quickest possible workaround, namely an
accept="image/jpeg"attribute for the image<input>tag. This solution is a proof of concept, so to say, and has two drawbacks: it does not accept X-PNG's or BMP's, and it remains fragile by not validating the image data on the server side. It's just a start to raise the issue. In a stronger solution, I think that thepicturepattern MIME type would need to be modified to"image/*inconfig.json, the image upload routines modified to prepend the image type to the image URI, and the file contents examined/checksummed server-side to prevent invalid data from being stored.Meanwhile, @babelouest I'd be grateful if you could provide a MySQL script to safely clean up invalid image data from my user records. My
g_user_propertydatabase table is full of dashes (-), which I presume is a sign of corruption.UPDATE: According to RFC 2046 (Section 4.2):
Therefore I'm revising (rebase-squashing) this PR to
accept="image/*". This allows the form to accept files of any "image" extension as profile photo. Setting thepicturepattern type to the genericimage/imageinconfig.jsonshould then be enough, because browsers are smart enough to infer the image format from its Base64 encoding (in RFC wording, browsers are "robust general-purpose image viewing applications"). Validating the data server-side would still be nice.Thanks again @yrammos ,
I think similar changes should be done in the profile page too, maybe in the login page as well: https://github.com/babelouest/glewlwyd/blob/yrammos-edit-user-modal-bugfix/webapp-src/src/Profile/User.js
Validating the image data on the server side is difficult, it would imply using an image library like imageMagick or something else, but mostly it would open a pandora box of complication on the server side which I don't want to maintain.
Worst-case scenario is if the user uploads garbage data as image, the result will be a non displayed image and I'm fine with that. If the user tries to find bugs to exploit, she/he wont' read the error messages, if the user uploaded a garbage image by mistake, she/he will reupload a good one.
To cleanup the images in the database, you can run the following SQL query:
Where
{USER}is the username with crappy imagesAgreed, @babelouest—and many thanks for the query.
—with the caveat that re-uploading seems impossible if garbage has already been uploaded (I tried it). This is why I asked for the query. But I'm personally OK with considering this a lunatic-fringe case (<.001 chance).False alarm. Please disregard last message.
Yeah, I was gonna talk about that, you can remove an image by clicking on it, but it's not obvious at all, I'll add a X or a trash icon to make it more ergonomic
@yrammos , I've added a trash icon on top right of the image like this: