Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(server): update user vs public user vs auth endpoints #9063

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

martabal
Copy link
Member

@martabal martabal commented Apr 24, 2024

Currently, all users have access to all information about other users such as the date they were created, quota usages, if memories is enabled...

This information should only be accessible by the administrators and the users themselves.

Copy link

cloudflare-pages bot commented Apr 24, 2024

Deploying immich with  Cloudflare Pages  Cloudflare Pages

Latest commit: 23784ab
Status: ✅  Deploy successful!
Preview URL: https://87dbde42.immich.pages.dev
Branch Preview URL: https://fix-restrict-userresponsedto.immich.pages.dev

View logs

@martabal martabal force-pushed the fix/restrict-userresponsedto branch from f5c02f2 to be49280 Compare April 24, 2024 18:31
@martabal martabal force-pushed the fix/restrict-userresponsedto branch from be49280 to e79ee7d Compare April 24, 2024 18:43
@martabal martabal marked this pull request as ready for review April 24, 2024 19:41
Copy link
Contributor

@jrasm91 jrasm91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I like the idea of differentiating between admin user endpoints and non admin ones, but I think the endpoints need to be adjusted. I was thinking all the existing user endpoints can eventually become admin only. Then we add a new endpoint for searching users that everyone else can use. We should migrate clients to this new one before changing anything about the old one.

The new one can maybe be something like GET /public-users. It would be best if it was in a separate controller.

@martabal
Copy link
Member Author

martabal commented Apr 25, 2024

In general I like the idea of differentiating between admin user endpoints and non admin ones, but I think the endpoints need to be adjusted. I was thinking all the existing user endpoints can eventually become admin only. Then we add a new endpoint for searching users that everyone else can use. We should migrate clients to this new one before changing anything about the old one.

The new one can maybe be something like GET /public-users. It would be best if it was in a separate controller.

Good idea! Where should be the getMyUserInfo endpoint? Does it make sense to move it to the auth controller ?

@jrasm91
Copy link
Contributor

jrasm91 commented Apr 25, 2024

Yes I think auth controller should make sense. Probably just /auth/user

@martabal martabal force-pushed the fix/restrict-userresponsedto branch 5 times, most recently from a3ca770 to fbefa67 Compare April 25, 2024 20:30
@martabal martabal force-pushed the fix/restrict-userresponsedto branch from fbefa67 to 304ee53 Compare April 25, 2024 20:38
@jrasm91
Copy link
Contributor

jrasm91 commented Apr 26, 2024

A few notes:

  • user profile methods are used by manually constructing the endpoint, so these need to be updated
  • removing getMyUser will be a breaking change for the mobile app for essentially everyone
  • password updates should happen via auth/reset-password, not "update user" the mobile app needs to migrate already
  • there are enough endpoints changing that we might want to take this opportunity to make any other breaking changes as well

@jrasm91 jrasm91 force-pushed the fix/restrict-userresponsedto branch from c760f24 to 23784ab Compare April 26, 2024 03:29
@jrasm91 jrasm91 changed the title fix(server): restrict UserResponseDto refactor(server): update user vs public user vs auth endpoints Apr 26, 2024
@alextran1502
Copy link
Contributor

I would like to take this opportunity to start building up a system for managing breaking changes/backward compatibility in API for the mobile app as well, so the endpoint that got deleted and caused breaking changes should be put back and marked as deprecated and will be removed in the future date

@jrasm91
Copy link
Contributor

jrasm91 commented Apr 26, 2024

This is going to be a bit complicated to do because there are probably 4-5 endpoints that fall into this category.

@jrasm91
Copy link
Contributor

jrasm91 commented Apr 26, 2024

If we have to do this in a non-breaking manner, I think we'll need to add the new endpoints for public users without changing any of the old implementations (a bit annoying). Then, in the future, update the endpoints to be admin-only, and simplify the implementation.

@martabal
Copy link
Member Author

Thinking about it, I don't feel good about admins being able to have access to all users' UserResponseDto, IMO they shouldn't know what preferences/features are enabled by other users, so I was thinking of having a new dto to represent users for administrators, something like UserAdminDto. So we have:

  • UserResponseDto which contains all information about the user (accessible only by the user himself)
  • UserAdminDto which is like UserResponseDto without user preferences (accessible only by admins)
  • UserDto which only has the user ID, name, email and avatar/profile photo (accessible to everyone)

@jrasm91
Copy link
Contributor

jrasm91 commented Apr 27, 2024

That sounds good @martabal! I was also thinking about it and we probably should add the new endpoints, then transition the web and mobile app to use them in the future and deprecate the old endpoints before finally removing the old ones.

Specifically we can add public users and new profile picture routes, get my auth user, but revert any changes that deleted old routes and revert the user core changes.

Once the mobile app stops using the old get my user and update user we can change those routes to return the admin user dto too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants