Permissions and access control

This guide explains how access to AISquare resources is controlled and how to handle permissions correctly in your application.

Overview

Access in AISquare depends on:

• Publication visibility
• User authentication
• User role and membership

Not all data is accessible to all users, and behavior may change depending on access level.

Publication visibility

Each AI Studio (publication) has a visibility setting.

Visibility types

How visibility affects access

Public

• Accessible without authentication
• Returns publicly available content

Team

• Requires authentication
• User must belong to the workspace

Private

• Requires authentication
• User must have explicit access

Permission check flow

AISquare provides a permission validation mechanism.

Endpoint

POST /api/v1/aistudios/permission/

Example request

1
{
2
  "url": "ai-research-studio"
3
}

What it does

• Validates if the user can access the publication
• Checks membership and roles
• May update workspace context

Access logic

The permission flow typically works like this:

1. Resolve publication from URL
2. Check visibility
3. Check authentication
4. Check membership or role
5. Grant or deny access

Response behavior

Workspace context

When access is granted:

• AISquare may set a workspace context (cookie)
• This ensures subsequent requests are scoped correctly

Roles and membership

Users may have different roles within a publication:

• Creator (owner)
• Co-creator (editor, reviewer, etc.)
• Workspace member

Role impact

Roles determine:

• Ability to view content
• Ability to edit or manage resources
• Access to metrics and analytics

Access patterns

Public content access

user → request → public data returned

Restricted content access

user → authenticate → permission check → access granted

Best practices

Always validate access

Before fetching protected data, call the permission endpoint.

Handle failures gracefully

• 401 → prompt login
• 404 → show not found or restricted

Cache permission results

Avoid repeated permission checks for the same user and publication.

Avoid assumptions

Do not assume all users have access to all publications.

Common mistakes

Skipping permission checks

Leads to unexpected failures in API calls.

Treating 404 as missing data

In some cases, 404 means access denied, not non-existence.

Ignoring workspace context

This may result in inconsistent behavior across requests.

Putting it all together

1. User selects studio
2. Backend checks permission
3. If allowed → fetch data
4. If denied → handle error

Related pages

• Authentication — set up credentials for permission checks
• AI Studios — publication-scoped endpoints
• Collections — visibility controls for collections
• Working with creators — creator and co-creator roles
• Errors — understand 401, 403, and 404 responses
• Core Concepts — entity visibility model