Prowler Api

What it does

This skill provides guidance and assistance for developing Prowler API workflows, specifically addressing its unique architecture and security considerations. It focuses on patterns related to Row-Level Security (RLS), Role-Based Access Control (RBAC), provider lifecycle management, Celery tasks within a tenant context, and multi-database configurations. This is not a general coding assistant; it's tailored for Prowler API development.

When to use it

This skill is useful in the following scenarios:

• Implementing Row-Level Security (RLS) or tenant isolation logic.
• Managing RBAC permissions and verifying user roles within the application.
• Validating provider lifecycle events and data integrity.
• Developing Celery tasks that require explicit tenant context.
• Working with Prowler's 4-database architecture, including understanding when to use each database (default, admin, replica, admin_replica).

Key capabilities

• Provides guidance on using rls_transaction(tenant_id) for secure queries outside of ViewSet contexts.
• Offers instructions on retrieving user roles with get_role().
• Details the correct order of decorators: @set_tenant then @handle_provider_deletion.
• Explains requirements for using explicit through models in M2M relationships to enforce RLS.
• Outlines best practices for Celery task development within a tenant context.

Example prompts

• "How do I ensure my query respects the current tenant's data?"
• "What is the correct way to check user permissions in Prowler?"
• "Explain how to use rls_transaction with a UUID."

Tips & gotchas

• RLS Context: Always use rls_transaction(tenant_id) when querying data outside of a ViewSet context.
• Database Selection: Be mindful of which database you're using (default, admin, replica, or admin_replica) and its implications for RLS enforcement. The 'admin' database bypasses RLS.
• M2M Relationships: Explicit through models are required for M2M relationships to function correctly with Row-Level Security.