I had a few things in mind. First, admin tokens should only be used for local development/testing. You never know, if or where it could be exposed in a future use case. When everything works, you can create tokens to query specific routes.
So xxToken1xx can query /api/collections/save/Guest. Now you can’t delete entries with this token → fine. But your intention is to allow only new entries. If you send an existing id, you can change entries.
To prevent this, you could play with user group permissions or with complicated context permissions (rules in the collection settings) or you can create custom api endpoints.
Registration
Create a file config/api/register-guest.php. You can query it with https://cockpit-url.com/api/register-guest and you can add an api token /api/register-guest. Here, the “specified filters” part isn’t relevant.
<?php
$data = $app->param('data');
// server side validation (never trust clients)
$validated = true;
if (!$validated) {
return ['error' => 'wrong'];
} else {
return $app->module('collections')->save('Guest', $data);
}
Removing old data
config/api/remove-guest.php:
Here you can simplify the cron script if you create hardcoded filters for a custom api endpoint.
<?php
$xdaysago = 14;
$filter = ['checkIn' => ['$lte' => $xdaysago]];
return $app->module('collections')->remove('Guest', $filter);
Now you only have to query https://cockpit-url.com/api/remove-guest without any filter.
If the cronjob is on the same server, you don’t even need curl. You could create a cli command instead and call a php script directly via crontab. But that’s another topic.
To summarize… Of course, you can use the nice and simple api and filters, that cockpit offers by default. But if you know, that you only need two api keys to do two very specific jobs, you don’t have to give more permissions than needed (like changing data, fetching different data than the own user, deleting data with custom filters etc.). Using custom endpoints just simplifies the permission management in this case.
