[Customer Portal] Handle forbidden access

[Rashmika998]

Description

This PR improves access control handling for protected endpoints by ensuring that forbidden access is properly detected and returned with meaningful error messages.

It standardizes how 403 Forbidden responses are sent to the frontend when users attempt to access resources without sufficient permissions.

---

Changes

• Added proper forbidden access handling for secured endpoints
• Updated error responses to return accurate HTTP status codes
• Improved error messages for better clarity on authorization failures

Affected endpoints:

• GET /users/me
• GET /projects/search
• GET /projects/:id
• GET /cases/:id

---

Benefits

• Prevents misleading 500 Internal Server Error responses
• Improves frontend error handling and user feedback
• Enhances overall API reliability

---

Example Scenario

When a user without required permissions attempts to access a protected resource, the API will now return:

• Status: 403 Forbidden
• Message: Access denied or insufficient permissions

Instead of a generic server error.

---

Related Issues

• Resolves [BE] Improve Error Handling for Project Get Endpoint #45

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Enhanced access control error handling for user profile, project search, project details, and case details endpoints.
  • System now properly returns access-denied responses with explanatory messages when users lack permission to access resources.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request adds runtime checks for HTTP 403 Forbidden responses across four customer portal backend endpoints, expanding their return type signatures to explicitly include http:Forbidden and mapping upstream forbidden errors to appropriate HTTP responses instead of generic 500 errors.

Changes

Cohort / File(s)	Summary
HTTP Error Handling for Forbidden Responses apps/customer-portal/backend/service.bal	Expanded return types for four endpoints (users/me, projects/search, projects/[string id], cases/[string id]) to include http:Forbidden. Added runtime checks inspecting entity service responses for http:STATUS_FORBIDDEN, logging warnings and returning explicit forbidden responses instead of proceeding to generic error handlers. Parameter references updated from caseId to id for consistency.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• PR #67 — Introduces a reusable getStatusCode helper and ERR_STATUS_CODE for extracting status codes from errors, which complements this PR's status code inspection logic in service endpoints.

Suggested labels

Type/Improvement, App/Customer Portal, Area/Backend

Suggested reviewers

• suhand

Poem

🐰 ✨ Four endpoints now catch the forbidden light,
No more 500s in the endless night,
Status codes inspected with careful care,
Clearer errors floating through the air! 🌟

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The description is present and contextually relevant but does not follow the required template structure with sections like Purpose, Goals, Approach, User Stories, and other standard sections.	Restructure the description to follow the required template format, including Purpose, Goals, Approach, Security checks, and other mandatory sections for clarity and consistency.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title '[Customer Portal] Handle forbidden access' clearly and concisely summarizes the main change—adding forbidden access handling to protected endpoints.
Linked Issues check	✅ Passed	The PR fully addresses issue #45 by inspecting error responses from entity calls, mapping status codes (including 403 Forbidden) to appropriate API responses, and avoiding generic 500 errors across all affected endpoints.
Out of Scope Changes check	✅ Passed	All code changes are directly related to handling forbidden access and improving error responses on the specified endpoints; no unrelated modifications were introduced.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/customer-portal/backend/service.bal (1)

267-299: Add forbidden error handling to this endpoint for consistency.

This endpoint calls searchCases, which wraps the same entity client call that can return 403 errors (like other similar endpoints). All other endpoints that call entity functions (getProjects, getProjectDetails, getCase, etc.) handle http:STATUS_FORBIDDEN and return http:Forbidden. This endpoint should do the same: add http:Forbidden to the return type union and check if getStatusCode(casesResponse) == http:STATUS_FORBIDDEN before processing the response.

🤖 Fix all issues with AI agents

In `@apps/customer-portal/backend/service.bal`:
- Around line 93-101: The warning log currently prints "User:" with a trailing
colon but no identifier, which is misleading; update the log in the
forbidden-check (the block using getStatusCode(userDetails) and log:printWarn)
to either remove the trailing colon and use a complete message like "User does
not have access to the customer portal" or include a safe placeholder until PR
`#42` adds the UUID (e.g., "User:<unknown>" or use userDetails.id if present).
Ensure you only change the string passed to log:printWarn in this forbidden
branch so the message is clear and non-misleading.
- Around line 147-155: The warning log message inside the
getStatusCode(projectsList) == http:STATUS_FORBIDDEN branch is grammatically
wrong and incomplete; update the log:printWarn call to a complete, grammatically
correct sentence and include the user identifier (UUID) once available (replace
the trailing colon-only message). Specifically, change the message to something
like "Access to the requested project is forbidden for user: <userId>" and
populate <userId> from the appropriate variable (or the UUID placeholder
referenced in the TODO) so the log prints the identifier; ensure the
http:Forbidden response body remains unchanged.

🧹 Nitpick comments (1)

apps/customer-portal/backend/service.bal (1)

93-101: Consider extracting forbidden handling into a helper function.

The forbidden response pattern is repeated across four endpoints with similar structure. You could extract this into a helper to reduce duplication and centralize the response format:

function createForbiddenResponse(string logMessage, string userMessage) returns http:Forbidden {
    log:printWarn(logMessage);
    return <http:Forbidden>{
        body: {
            message: userMessage
        }
    };
}

This would simplify each check to a single function call and make future updates (like adding the UUID from PR #42) easier.

Also applies to: 147-155, 194-202, 241-249