Authentication and Authorization Security Fixes

[mohab-elshamy]

Summary

This PR improves authentication, authorization, and data exposure across several APIs.

The changes focus on ensuring that:

• authenticated actions always use the identity from the current session.
• users can only modify resources they are authorized to access.
• private project data is not exposed through nested API responses or notifications.
• sensitive account information is not serialized unnecessarily.
• privileged operations such as arbitrary email delivery are restricted appropriately.

The implementation reuses the existing authorization patterns, project roles, admin configuration, and claim-based user identity without introducing a new authorization framework or database migrations.

What was fixed

Authentication

• Fixed a login issue where a password could be verified against one account while a session was issued for another account under a username/email collision.
• Login now always creates the session for the exact User whose password was successfully verified.

Sensitive data exposure

• Replaced raw EF/Identity entity responses with explicit response projections.
• Prevented exposure of authentication-related fields such as password hashes, security stamps, refresh tokens, normalized login fields, and other internal account data.
• Limited private account fields such as email and notification settings to the account owner or administrators.
• Prevented nested project responses from exposing unnecessary project files, notebooks, comments, logs, membership requests, and reverse navigation graphs.
• Filtered private project membership information based on whether the current user can view the project.

Project fork authorization

• Forked files are now validated against the source project.
• A user can no longer provide a BlobFileID belonging to another project when forking.

Profile image deletion

• Restricted profile image deletion to the authenticated user's own profile image.
• Project files and other users' blobs can no longer be deleted through the profile image endpoint.

File movement

• Added authentication to MoveFile.
• Authorization is now based on the file's stored ProjectID.
• Only the project owner can move project files.

Publications

• Creating, updating, and deleting publications now requires an active owner or member role in the relevant project.
• Followers and non-members receive 403 Forbidden.

Project logs

• Creating project logs now requires current project membership.
• Updating, deleting, and reposting logs validate both project membership and log ownership where applicable.
• Existing administrator moderation behavior is preserved.

Comments

• Comment creation, updates, likes, and reports now respect project visibility.
• Users who lose access to a private project can no longer continue interacting with its comments.

Notifications

• Private-project notifications are filtered according to the recipient's current project access.
• Former members or followers no longer receive private log/comment notifications or related emails.
• Stored notifications are also filtered when retrieved, counted, or marked as read.
• Project invitations remain accessible to the invited user with only the limited information required to identify and accept the invitation.

Email delivery

• Restricted the general-purpose SendEmail endpoint to authenticated administrators.
• Registration, confirmation, and password-reset email flows remain unchanged.