Skip to content
This repository has been archived by the owner on Aug 30, 2021. It is now read-only.

Unlink old(previous) profile images #1415

Closed
aanev opened this issue Jul 28, 2016 · 6 comments · Fixed by #1425
Closed

Unlink old(previous) profile images #1415

aanev opened this issue Jul 28, 2016 · 6 comments · Fixed by #1425

Comments

@aanev
Copy link
Contributor

aanev commented Jul 28, 2016

Currently old profile images are not unlinked upon change and remain on disk. If a user changes his/her profile image frequently that can lead to disk space leakage.

@mleanos
Copy link
Member

mleanos commented Jul 28, 2016

This is something that has crossed my mind as well.

I think we have a couple options:

  1. Remove previous profile image after successful upload
    OR
  2. Overwrite existing profile image, using the same file name

The latter may be a less complicated implementation, but could have security implications when we're using the same file name over long periods of time (or for the lifetime of the profile image). However, this is just a profile image that isn't a private asset.

@aanev
Copy link
Contributor Author

aanev commented Jul 28, 2016

IMHO both options are fine. However, I think the first one will be easier to implement and with less changes to existing code. Something like that:

  1. Save reference to the old file.
  2. Upload new one.
  3. In the upload callback update the db with the new file name and fs.unlink the old one if it's different from the default image.

@mleanos
Copy link
Member

mleanos commented Jul 30, 2016

@aanev Your proposed solution is fine, and would work. Most likely requiring just 4 lines of code in this method.

However, I'd like to see this done in a more configurable manner, and the actual deletion abstracted away from the User's profile server controller. Whether or not to delete, or overwrite, the existing profile picture seems to be more of a business requirement that may vary among this framework's users. It would be nice to provide an option for allowing our users full control over this.

@lirantal
Copy link
Member

@aanev good catch.

I think we should simplify this, whether we overwrite an existing file name, or create a new one, both are ok. Is anyone getting a PR proposed?

@mleanos
Copy link
Member

mleanos commented Jul 30, 2016

@aanev Would you like to submit a PR for this?

If we opted for overwriting the existing file by using the same name, we wouldn't have a need to update the database. I fiddled around with this idea, and wasn't able to change the file name before upload on the client-side. I'm not sure if this is a limitation of angular-file-upload, or with our implementation of it. The solution in this comment didn't work for me. We could always remove the old file, and rename the new one on the server-side after the successful upload; we wouldn't need to update the database in this case either. Just food for thought :)

Either option we go with, we can keep it simple as @lirantal suggested.

@lirantal
Copy link
Member

Tested and it looks good.
Thanks @aanev and @mleanos

lirantal pushed a commit that referenced this issue Aug 26, 2016
* fix(user): fix changeProfilePicture

* use promises to simplify callbacks

* use fs.unlink to delete old picture once the profile is updated

Fixes #1415

* fix(user): fix changeProfilePicture

* use promises to simplify callbacks

* use fs.unlink to delete old picture once the profile is updated

* log file errors to console

Fixes #1415

* fix(user): fix changeProfilePicture

* use promises to simplify callbacks

* use fs.unlink to delete old picture once the profile is updated

* log file errors to console

* update error handler module to handle file upload errors

Fixes #1415

* fix(user): fix changeProfilePicture

* use promises to simplify callbacks

* use fs.unlink to delete old picture once the profile is updated

* log file errors to console

* update error handler module to handle file upload errors

Fixes #1415
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants