Got a Docker Compose file? Your project goes live in seconds — one command on cdn.com.tr. See how Built your app with AI? From folder to live URL with one command — no git, no registry: cdnctl deploy. See how Code on GitHub? Every push auto-deploys to cdn.com.tr — connect your repo and ship. See how

CDN.com.tr Help

Team roles: viewer, editor and owner

Give each colleague their own login and the smallest role that lets them do their job. The same role is enforced on the API, so a bearer token can never do more than the person it belongs to.

Organization, permissions, support

Team roles: viewer, editor and owner

Give each colleague their own login and the smallest role that lets them do their job. The same role is enforced on the API, so a bearer token can never do more than the person it belongs to.

What roles are for

Roles and the activity record are the same feature seen from two sides: one limits what can happen, the other records what did.

The record

Activity history

Who changed what, with before and after values — readable only because each person has their own login.

Open the topic
The page itself

Sub-users and permissions

Creating, updating and deactivating the users these roles are attached to.

Open the topic
Background

CDN activity log and team roles

Least privilege and an audit trail as one requirement, and how to answer it in a tender.

Read the guide

Panel path

  1. Management Panel
  2. Authorization
  3. Create New User
  4. Role

Prerequisites

  • Only the account owner can create sub-users and set roles.
  • Each person needs their own email address; the audit trail is worth nothing if two people share one.
  • Decide the role before you create the user — it is easier than explaining a permission gap later.

Decision model

Which role does this person need?

Pick by the smallest thing that unblocks them, not by seniority.

  • Viewer: reporting, monitoring, an agency that only reads consumption and cache numbers.
  • Editor: the developer or publisher who purges after a deploy, edits delivery rules, and manages DNS and certificates.
  • Owner: you, and anyone you would trust with billing and with adding other users.

One login or one per person?

This choice decides whether the audit log can ever answer a question.

  • One login per person: every row in Activity history names a real human.
  • A shared login: every action looks identical, and removing one person means changing the password for everyone.

Step-by-step guide

1

Create the user

Authorization is the page that owns sub-users for the whole customer, not per account.

  • Open Authorization and click Create New User.
  • Fill in first name, last name, email, phone and the password twice.
  • Do not submit yet — the role list is at the bottom of the same form.

Expected result: The new user form is filled in and the role table is visible below the password fields.

cdnctl equivalent 
POST /api/subusers
2

Set the role

The role table lists the roles with an inactive/active switch on each. Turn on the one the person needs.

  • Switch on Viewer (read-only) for someone who only reads reports.
  • Switch on Editor for someone who purges, or edits delivery rules, DNS or certificates.
  • Leave everything off only if you want a viewer — that is what an empty role falls back to.
  • Click Create User.

Expected result: The user is created with exactly the role you chose, and can sign in with their own credentials.

cdnctl equivalent 
GET /api/roles
3

Confirm the boundary holds

Verify from the new account, not from yours. This is a two-minute check that prevents a bad surprise.

  • Have the person sign in and open the pages they need.
  • Ask a viewer to try saving something and confirm they are refused.
  • Open Activity history and confirm their actions are recorded under their own name.

Expected result: The person can do their job, is blocked from everything else, and every action they take is attributable.

cdnctl equivalent 
GET /api/accounts/<account_uuid>/activities?per_page=25

Verification

  • A viewer can open every page but cannot save anything except their own profile and password.
  • An editor can purge and edit delivery rules but has no sub-user or billing actions.
  • A token issued to a sub-user is refused on the endpoints their role does not cover.
  • Activity history names the sub-user, not the owner, after they make a change.

Use cases

Two or three people work on the same CDN account: one publishes and needs to purge, one only reads the reports, and only you should be able to add users or touch billing. A shared password gives all three the same power and makes the audit log useless.

Quick workflow

  1. Open Authorization and create a user for each person instead of sharing one login.
  2. Set the role on the new user: viewer for read-only, editor for day-to-day operations, owner for full control.
  3. Have the person sign in and confirm they can do their work and nothing beyond it.
  4. Check Activity history afterwards: their actions now appear under their own name.

Checks

  • Viewer: reads every page, and can change their own profile and password. No other writes.
  • Editor: purge, delivery rules, DNS, certificates and hostnames. No sub-user management, no billing, no account deletion.
  • Owner: everything, including users and billing. This is the role the account signed up with.
  • Leaving the role empty makes the user a viewer. A new user is never created with more power than you granted.
  • The API applies the same rules. A viewer token cannot write, and an editor token is refused on owner-only endpoints.