MyVideoGameList/myvideogamelist.com
MyVideoGameList/myvideogamelist.com
3
0
Fork 0
Code Issues 45 Pull requests Projects 3 Releases Activity Actions

Restrict Remove Friend controls to the signed-in user’s own friend lists #33

New issue
Closed
opened 2024-01-14 14:36:32 -06:00 by jimmyb · 1 comment
jimmyb commented 2024-01-14 14:36:32 -06:00
Owner
Copy link

Friend action ownership needs to be rebuilt so authenticated users cannot see or use Remove Friend controls while viewing another user's Friends or Friends Of pages.

The original issue reported that a signed-in user could see Remove Friend on a friend list that was not theirs. The rebuilt friending feature now enforces ownership through the user_friends model, authenticated mutation routes, profile-only friend actions, and read-only Friends/Friends Of list pages.

Scope

  • Friends and Friends Of list pages or tabs, where implemented.
  • Remove Friend controls/forms/links.
  • Add Friend controls where they appear beside listed users.
  • Current viewer, profile/list owner, and listed-user relationship state.
  • Server-side authorization for friend mutations.

Acceptance Criteria

  • Authenticated users only see Remove Friend controls for friend relationships they own.
  • Authenticated users do not see Remove Friend controls while browsing another user's Friends or Friends Of list unless the row represents a relationship owned by the current viewer.
  • Users cannot remove another user's friend relationship by submitting crafted requests.
  • Guests never see Add Friend or Remove Friend controls on friend list surfaces.
  • Add Friend controls, where shown, target only valid active users and never the current user.
  • Friend action visibility is consistent between profile action areas, Friends lists, and Friends Of lists.
  • Banned, deleted, soft-deleted, or missing users do not expose friend actions.
  • Friend list rows remain readable even when actions are hidden.
  • User-facing UI supports light/dark mode and follows the existing Laravel/Tailwind site layout patterns.

Test Coverage Required

  • Feature tests confirming Remove Friend is visible only for the signed-in user's own friend relationships.
  • Feature tests confirming Remove Friend is hidden while viewing another user's friend lists.
  • Feature tests confirming forged remove-friend requests cannot remove relationships owned by another user.
  • Feature tests for guest visibility, self-user rows, banned/deleted users, and empty friend list states.
  • Regression tests covering Friends and Friends Of pages/tabs separately.
  • Tests should use Pest and focused feature coverage.
  • Run the focused affected tests, then run vendor/bin/pint --dirty before closing the issue.

Progress Checklist

  • Public profile page exists
  • Profile stats reserve Friends and Friends Of rows
  • Notification settings include friend_added_you
  • Add or confirm friend persistence and ownership model
  • Add Friends and Friends Of list pages or tabs
  • Add server-side authorization for remove-friend actions
  • Show Remove Friend only for relationships owned by the current viewer
  • Hide friend mutation controls when viewing another user's unrelated friend list
  • Handle guests, self-user rows, deleted users, banned users, and empty states
  • Add tests for friend action ownership, forged requests, and list rendering
  • Confirm friend action UI matches expected ownership behavior
Friend action ownership needs to be rebuilt so authenticated users cannot see or use Remove Friend controls while viewing another user's Friends or Friends Of pages. The original issue reported that a signed-in user could see Remove Friend on a friend list that was not theirs. The rebuilt friending feature now enforces ownership through the user_friends model, authenticated mutation routes, profile-only friend actions, and read-only Friends/Friends Of list pages. ## Scope - Friends and Friends Of list pages or tabs, where implemented. - Remove Friend controls/forms/links. - Add Friend controls where they appear beside listed users. - Current viewer, profile/list owner, and listed-user relationship state. - Server-side authorization for friend mutations. ## Acceptance Criteria - Authenticated users only see Remove Friend controls for friend relationships they own. - Authenticated users do not see Remove Friend controls while browsing another user's Friends or Friends Of list unless the row represents a relationship owned by the current viewer. - Users cannot remove another user's friend relationship by submitting crafted requests. - Guests never see Add Friend or Remove Friend controls on friend list surfaces. - Add Friend controls, where shown, target only valid active users and never the current user. - Friend action visibility is consistent between profile action areas, Friends lists, and Friends Of lists. - Banned, deleted, soft-deleted, or missing users do not expose friend actions. - Friend list rows remain readable even when actions are hidden. - User-facing UI supports light/dark mode and follows the existing Laravel/Tailwind site layout patterns. ## Test Coverage Required - Feature tests confirming Remove Friend is visible only for the signed-in user's own friend relationships. - Feature tests confirming Remove Friend is hidden while viewing another user's friend lists. - Feature tests confirming forged remove-friend requests cannot remove relationships owned by another user. - Feature tests for guest visibility, self-user rows, banned/deleted users, and empty friend list states. - Regression tests covering Friends and Friends Of pages/tabs separately. - Tests should use Pest and focused feature coverage. - Run the focused affected tests, then run vendor/bin/pint --dirty before closing the issue. ## Progress Checklist - [x] Public profile page exists - [x] Profile stats reserve Friends and Friends Of rows - [x] Notification settings include friend_added_you - [x] Add or confirm friend persistence and ownership model - [x] Add Friends and Friends Of list pages or tabs - [x] Add server-side authorization for remove-friend actions - [x] Show Remove Friend only for relationships owned by the current viewer - [x] Hide friend mutation controls when viewing another user's unrelated friend list - [x] Handle guests, self-user rows, deleted users, banned users, and empty states - [x] Add tests for friend action ownership, forged requests, and list rendering - [x] Confirm friend action UI matches expected ownership behavior
2fe8b500-309d-11ea-8eb6-cf3068291259.png
414 KiB
2fe8b500-309d-11ea-8eb6-cf3068291259.png
Codex changed title from Hide ''Remove Friend'' on other users friend lists to Restrict Remove Friend controls to the signed-in user’s own friend lists 2026-05-25 22:22:11 -05:00
jimmyb self-assigned this 2026-06-01 19:48:30 -05:00
Codex commented 2026-06-01 19:52:38 -05:00
Member
Copy link

Reviewed against the rebuilt friending feature from issue #55 and this is now covered.

Evidence:

  • Friend persistence is modeled in user_friends with directed user_id -> friend_id ownership.
  • POST/DELETE profile friend routes are authenticated.
  • Remove uses the signed-in user's id plus the target friend id, so a crafted request cannot remove another user's relationship.
  • Friends and Friends Of pages are read-only list surfaces and do not render Add/Remove controls for guests or authenticated viewers.
  • Profile Add/Remove controls render only for logged-in non-self viewers, and activePublic filtering prevents banned, deleted, soft-deleted, or missing users from exposing friend actions.

Verification run:

  • php artisan test --compact tests/Feature/UserFriendTest.php tests/Feature/UserProfileTest.php
  • Result: 30 passed, 213 assertions
Reviewed against the rebuilt friending feature from issue #55 and this is now covered. Evidence: - Friend persistence is modeled in user_friends with directed user_id -> friend_id ownership. - POST/DELETE profile friend routes are authenticated. - Remove uses the signed-in user's id plus the target friend id, so a crafted request cannot remove another user's relationship. - Friends and Friends Of pages are read-only list surfaces and do not render Add/Remove controls for guests or authenticated viewers. - Profile Add/Remove controls render only for logged-in non-self viewers, and activePublic filtering prevents banned, deleted, soft-deleted, or missing users from exposing friend actions. Verification run: - php artisan test --compact tests/Feature/UserFriendTest.php tests/Feature/UserProfileTest.php - Result: 30 passed, 213 assertions
Codex closed this issue 2026-06-01 19:52:38 -05:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
dev
No results found.
Labels
Clear labels   
automated

   
code-quality

   
component: admin dashboard
The issue is related to the admin dashboard functionality.

  
component: backend
The issue is related to the backend code.

  
component: billing
The issue is related to our billing and payment system functionality.

  
component: content management
The issue is related to site content and moderation functionality.

  
component: faqs
The issue relates to our frequency asked questions and their categories.

  
component: game genres
The issue is related to genres in relation to games.

  
component: game lists
The issue is related to user-facing game list functionality.

  
component: game reviews
The issue relates to the game reviews functionality.

  
component: game search
The issue is related to the user-facing game search functionality.

  
component: games
The issue relates to games in our database.

  
component: internal notifications
The issue is related to the functionality of notifications sent for internal usage.

  
component: platforms
The issue is related to platform functionality.

  
component: security
The issue relates to the security issues within the app.

  
component: tests
The issue relates to unit and feature tests.

  
component: user api
The issue relates to the user-facing API.

  
component: user badges
The issue is related to our badge/achievements functionality.

  
component: user blogs
The issue is related to blogging functionality.

  
component: user consoles
The issue is related to user console lists functionality.

  
component: user favorites
This is issue is related to the favorites functionality.

  
component: user friends
The issue relates to the friending functionality.

  
component: user notifications
The issue is related to user-facing notifications functionality.

  
component: user profiles
The issue is related to user profile functionality.

  
component: user site notifications
The issue relates to the functionality of notifications shown to users directly on the website.

  
component: user wishlists
This issue is related to the wishlists functionality.

  
component: web design
This issue is related to the design of the website.

  
dependencies
Pull requests that update a dependency file.

  
php
Pull requests that update PHP code.

  
priority
high
 The issue is considered a high priority.

  
priority
low
 This issue is considered a low priority.

  
priority
medium
 This issue is considered a medium priority.

  
security-hotspot

   
source: codex

   
source: sonarqube
  
status
awaiting feedback
 The issue is awaiting feedback from others.

  
status
backlog
 Issues that are in a backlog status.

  
status
done
 The issue has been completed and closed out.

  
status
in progress
 The issue is in progress and being actively worked on.

  
status
in queue
 The issue is in queue and will be worked on shortly.

  
status
in review
 The issue work has been completed and now the work needs to be reviewed.

  
status
needs codex review
 Use this tag to have Codex spiffy up your issue.

  
status
needs investigation
 The issue describes a problem which needs further investigation.

  
status
wontfix
 This issue will not be worked on.

  
type: bug
The issue describes something working the way it wasn't intended too.

  
type: documentation
Improvements or additions to site documentation.

  
type: feature
A new feature for the website.

  
type: improvement
An improvement on an existing feature.

  
type: regression
The issue describes a function that previously worked and no longer does.

  
type: task
A small-ish task.

No labels
automated
code-quality
component: admin dashboard
component: backend
component: billing
component: content management
component: faqs
component: game genres
component: game lists
component: game reviews
component: game search
component: games
component: internal notifications
component: platforms
component: security
component: tests
component: user api
component: user badges
component: user blogs
component: user consoles
component: user favorites
component: user friends
component: user notifications
component: user profiles
component: user site notifications
component: user wishlists
component: web design
dependencies
php
priority
high
priority
low
priority
medium
security-hotspot
source: codex
source: sonarqube
status
awaiting feedback
status
backlog
status
done
status
in progress
status
in queue
status
in review
status
needs codex review
status
needs investigation
status
wontfix
type: bug
type: documentation
type: feature
type: improvement
type: regression
type: task
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Laravel 13 + TailwindCSS
Assignees
Clear assignees
No assignees
jimmyb
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
MyVideoGameList/myvideogamelist.com#33
No description provided.