Skip to content

PM-5895: send auth token when loading review opportunities - #7268

Merged
jmgasper merged 1 commit into
developfrom
PM-5895
Aug 21, 2026
Merged

PM-5895: send auth token when loading review opportunities#7268
jmgasper merged 1 commit into
developfrom
PM-5895

Conversation

@jmgasper

Copy link
Copy Markdown
Collaborator

What was broken

Private (group restricted) challenges were listed in the Open for Review bucket of the community app Opportunities page for anonymous visitors and for members who are not part of the challenge group.

After the review API started enforcing group visibility, the opposite problem showed up (see the comment on PM-5895): the review opportunities of group challenges stopped being visible to admins and to members of those groups as well.

Root cause

The community app called the v6 review opportunity endpoints without an Authorization header:

  • GET /v6/review-opportunities
  • GET /v6/review-opportunities/{opportunityId}

Both endpoints evaluate challenge group access against the calling user, so every community app request was treated as anonymous. An anonymous caller only receives opportunities of public challenges, so group challenges could never be shown to the admins and group members who are entitled to see them — while older API builds that did not filter at all exposed them to everyone.

What was changed

  • src/shared/services/reviewOpportunities.js — added a shared getRequestOptions helper that attaches Authorization: Bearer <tokenV3> when a token is available, and used it for both the listing and the details requests.
  • src/shared/actions/challenge-listing/index.jsgetReviewOpportunitiesDone accepts tokenV3 and forwards it to the service.
  • src/shared/containers/challenge-listing/Listing/index.jsx — the load-more handler and the mapDispatchToProps binding pass the logged in user's tokenV3.
  • src/shared/actions/page/review-opportunity-details.jsgetDetailsDone forwards the tokenV3 that the details container was already dispatching.

No API change was required. review-api-v6 already filters challenge ids by challenge groups and bypasses that filter for admin/M2M callers. This was verified against api.topcoder-dev.com: for a grouped challenge with an OPEN review opportunity, the search endpoint returns the opportunity for an M2M caller and returns nothing for an anonymous caller, and /review-opportunities/challenge/{id} returns 403 FORBIDDEN_CHALLENGE_WHITELIST anonymously.

Any added/updated tests

  • __tests__/shared/services/reviewOpportunities.js — new auth token forwarding suite:
    • the Authorization header is sent when listing review opportunities with a token,
    • the header is omitted for anonymous listing requests,
    • both details requests carry the header when a token is supplied.

Commands run: npm run jest -- __tests__/shared/services/reviewOpportunities.js (6 passed), npm run lint:js (clean), npm run build.

🤖 Generated with Claude Code

What was broken
Private (group restricted) challenges were listed in the "Open for Review"
bucket of the community app Opportunities page for anonymous visitors and for
members who are not part of the challenge group. After the review API started
enforcing group visibility, the opposite problem appeared: the opportunities of
group challenges were no longer visible to admins or to members of those
groups either.

Root cause
The community app called the v6 review opportunity endpoints without an
Authorization header. GET /v6/review-opportunities (and
GET /v6/review-opportunities/{id}) evaluate challenge group access against the
caller, so every community app request was treated as anonymous. An anonymous
caller must only receive opportunities of public challenges, which is why the
listing could never show group challenges to the members entitled to see them,
while older API builds that did not filter at all exposed them to everybody.

What was changed
- services/reviewOpportunities: added a shared getRequestOptions helper that
  attaches "Authorization: Bearer <tokenV3>" when a token is available, and
  used it for both the review opportunity listing and the details requests.
- actions/challenge-listing: getReviewOpportunitiesDone now accepts tokenV3 and
  forwards it to the service.
- containers/challenge-listing/Listing: the load-more handler and the
  mapDispatchToProps binding pass the logged in user's tokenV3.
- actions/page/review-opportunity-details: getDetailsDone forwards the tokenV3
  that the details container was already dispatching.

No API change was required: review-api-v6 already filters challenge ids by
challenge groups (and bypasses that filter for admin and M2M callers), which
was verified against api.topcoder-dev.com where a grouped challenge's OPEN
review opportunity is returned for an M2M caller and withheld from an
anonymous caller.

Any added/updated tests
- __tests__/shared/services/reviewOpportunities.js: new "auth token
  forwarding" suite asserting the Authorization header is sent for the listing
  and details requests when a token is present, and omitted for anonymous
  listing requests.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jmgasper
jmgasper requested a review from kkartunov as a code owner August 20, 2026 06:54
@jmgasper
jmgasper merged commit ae78fea into develop Aug 21, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant