feat: management apis for apps, envs, access

[rohan-chaturvedi]

🔍 Overview

Provide a brief overview of the context and the problem your pull request aims to solve. Include any relevant background information to help reviewers understand the current situation.

💡 Proposed Changes

Detail the proposed changes, including new features, bug fixes, or improvements. Explain how these changes impact the project, including any internal structure alterations or refactorings.

🖼️ Screenshots or Demo

Include before and after screenshots or animated GIFs/demo links to illustrate the changes visually. This is especially useful for UI/UX improvements.

📝 Release Notes

Summarize the changes in a user-friendly manner. Highlight new features, bug fixes, and any breaking changes, including migration steps or deprecated functionalities.

❓ Open Questions

If there are aspects of the changes that you're unsure about or would like feedback on, list them here.

🧪 Testing

Describe the testing strategy. List new tests added, existing tests modified, and any testing gaps.

🎯 Reviewer Focus

Guide the reviewer on where to start the review process. Suggest specific files, modules, or functionalities to focus on as entry points.

➕ Additional Context

Provide any additional information that might be helpful for reviewers and future contributors, such as links to related issues, discussions, or resources.

✨ How to Test the Changes Locally

Give clear instructions on how to test the changes locally, including setting up the environment, any necessary commands, or external dependencies.

💚 Did You...

• Ensure linting passes (code style checks)?
• Update dependencies and lockfiles (if required)
• Update migrations (if required)
• Regenerate graphql schema and types (if required)
• Verify the app builds locally?
• Manually test the changes on different browsers/devices?

In general, to fix information exposure through exceptions in web views, avoid returning raw exception messages (or stack traces) directly to clients. Instead, log the detailed error on the server and return a generic, user-friendly error message that does not reveal internal details. Only expose specific, curated validation messages if they are intentionally designed and controlled.

For this specific code, the best targeted fix is to stop returning str(e) to the client from the except ValueError as e: block. We can keep the HTTP status code as 403_FORBIDDEN to preserve existing behavior, but change the response body to either a fixed message (for example, "Invalid service account configuration." or "Unable to create service account.") and optionally log the original exception using the existing logger. This preserves functionality from the client's perspective (an error with the same status) while removing the direct leak. Concretely, in backend/api/views/service_accounts.py, around lines 205–209, replace:

        except ValueError as e:
            return Response(
                {"error": str(e)},
                status=status.HTTP_403_FORBIDDEN,
            )

with something like:

        except ValueError as e:
            logger.warning("Failed to create service account: %s", e)
            return Response(
                {"error": "Unable to create service account."},
                status=status.HTTP_403_FORBIDDEN,
            )

No new imports are needed because logger is already defined at the top of the file.

In general, the problem is fixed by not sending raw exception messages (or stack traces) back to the client. Instead, log the exception details on the server and return a generic and stable error message (optionally using an error code) in the HTTP response. This preserves debuggability for developers while avoiding information disclosure to users.

For this specific code in backend/api/views/apps.py, we will change the except ValueError as e: block so that:

• The full exception (with message) is logged using the existing logger defined at the top of the file (logger = logging.getLogger(__name__)).
• The HTTP response body will contain a generic message such as "An invalid value was provided." rather than str(e).
• The HTTP status code (400 BAD_REQUEST) remains the same to preserve existing functionality and API semantics.

Concretely, we will:

1. Modify the except ValueError as e: block around lines 243–247.
2. Add a call to logger.warning or logger.error (e.g., logger.warning("Failed to create app due to invalid value", exc_info=e)).
3. Replace {"error": str(e)} with a safer, generic message, e.g., {"error": "Invalid data provided."}.

No new imports or helper methods are required because logging and logger are already defined in this file.

In general, to fix this class of issues, avoid returning raw exception messages or stack traces to clients. Instead, either (a) map expected, safe exceptions to controlled, user-friendly messages, or (b) return a generic error message while logging the detailed exception internally.

Here, the minimal, non-breaking change is to replace {"error": str(e)} with a generic, stable error message that conveys the problem type without exposing implementation details. Since this block already sets an appropriate 400 status code, we can keep that behavior and just adjust the error string. No new imports or helpers are strictly required; logging is outside the shown snippet and can’t be safely modified. Concretely, in backend/api/views/environments.py, within the post method around lines 122–135, update the except ValueError as e: block so that it returns a fixed message such as {"error": "Invalid environment data."} (or similar) instead of str(e).