If I used a private db, I have different uses and permissions for different tables. I'm trying to figure out how I can setup the table permissions in a similar way in CloudKit.
For example, a countries table (admin:read/write, user:read)
Next, a users table (admin:read/write, user:read/limited write)
For example, a countries table (admin:read/write, user:read)
Only managed by an admin
The data can be read by any user but not updated
Data will be populated before any users have the app
Next, a users table (admin:read/write, user:read/limited write)
When a user signs up, a new record is added.
A user should have read and write access to only their record.
Admins should have read and write access to all records.
You want to look into the Security Roles available in CloudKit Dashboard. There are three default flavors of roles: World, Authenticated, and Creator.
World: Everyone with app access, no CloudKit sign in required (read only)
Authenticated: User of your app signed into iCloud
Creator: The user that created the record, i.e. the same userID populated in the "creatorUserRecordID" field aka 'createdBy' if you're familiar with that term from other technologies
You can also create your own role which presents itself as a checkbox on the "user" record type in the CloudKit Dashboard.
I'm building out an app that will use a 'custom app' distributed to businesses, and then a user facing app on the App Store. These two applications will use the same CloudKit Container and use roles to achieve some read-only sections of the public database, and others that are create/read/write. I have created an "Admin" role very similar to what you are doing above.
So for your scenario, change the default permissions on the Authenticated role and remove the create and write permissions (do this for every record type). Next, create the new role, and assign to the users you want to be able to update. If the user set that need write access is large, you could explore using tokens--though I haven't tried this before.
Please note, if you create new record types, be sure to remember to uncheck the permissions you want to restrict for authenticated and setup your admin role respectively before you deploy your schema to production!
World: Everyone with app access, no CloudKit sign in required (read only)
Authenticated: User of your app signed into iCloud
Creator: The user that created the record, i.e. the same userID populated in the "creatorUserRecordID" field aka 'createdBy' if you're familiar with that term from other technologies
You can also create your own role which presents itself as a checkbox on the "user" record type in the CloudKit Dashboard.
I'm building out an app that will use a 'custom app' distributed to businesses, and then a user facing app on the App Store. These two applications will use the same CloudKit Container and use roles to achieve some read-only sections of the public database, and others that are create/read/write. I have created an "Admin" role very similar to what you are doing above.
So for your scenario, change the default permissions on the Authenticated role and remove the create and write permissions (do this for every record type). Next, create the new role, and assign to the users you want to be able to update. If the user set that need write access is large, you could explore using tokens--though I haven't tried this before.
Please note, if you create new record types, be sure to remember to uncheck the permissions you want to restrict for authenticated and setup your admin role respectively before you deploy your schema to production!
