Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
Authorizationheader:GET /v6/review-opportunitiesGET /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 sharedgetRequestOptionshelper that attachesAuthorization: Bearer <tokenV3>when a token is available, and used it for both the listing and the details requests.src/shared/actions/challenge-listing/index.js—getReviewOpportunitiesDoneacceptstokenV3and forwards it to the service.src/shared/containers/challenge-listing/Listing/index.jsx— the load-more handler and themapDispatchToPropsbinding pass the logged in user'stokenV3.src/shared/actions/page/review-opportunity-details.js—getDetailsDoneforwards thetokenV3that the details container was already dispatching.No API change was required.
review-api-v6already filters challenge ids by challenge groups and bypasses that filter for admin/M2M callers. This was verified againstapi.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}returns403 FORBIDDEN_CHALLENGE_WHITELISTanonymously.Any added/updated tests
__tests__/shared/services/reviewOpportunities.js— newauth token forwardingsuite:Authorizationheader is sent when listing review opportunities with a token,Commands run:
npm run jest -- __tests__/shared/services/reviewOpportunities.js(6 passed),npm run lint:js(clean),npm run build.🤖 Generated with Claude Code