Feature request: Restrict access to GET /item and GET /stock to the clans to which they belong

[tickBit]

What do you want to see in the API?

GET /item/{id} and GET /stock/{id} should not return 200 OK when the requested resource belongs to another clan.

They should return an authorization error, preferably 403 Forbidden, when the resource exists but is outside the logged-in player’s clan scope.

How do you think this should work?

Both endpoints should verify that the requested item/stock belongs to the authenticated player’s clan before returning any data.

Expected behavior:

• If the resource belongs to the logged-in player’s clan: return 200 OK.
• If the resource exists but belongs to another clan: return 403 Forbidden.
• If the resource does not exist: return 404 Not Found.

Current behavior appears inconsistent: GET /room/{id} returns 404 for another clan’s room, but GET /item/{id} and GET /stock/{id} return 200.

Any additional info?

GET /item/{id} currently reads the item directly by ID, and the item authorization rule allows general read access. GET /stock/{id} reads items by stock ID, so the stock-level response rule may not protect the returned item data correctly.

This should be tightened so clan inventory data cannot be read by authenticated users from other clans.