История изменений
Исправление ThisNameWasFree, (текущая версия) :
Простейший вариант на 4 таблицы:
api_components (функционал проекта делится на компоненты/секции, к которым в дальнейшем будете раздавать доступ):
> id int(11)
> name varchar(128)
api_tokens (сами токены, в данном примере токен имеет длину 32 символа):
> id int(11)
> name varchar(32)
> is_active tinyint(1)
api_rules (правила доступа для токенов - раздаёте на указанный токен определённые компоненты/секции):
> id int(11)
> token_id int(11)
> component_id int(11)
api_log (логи доступа к компонентам/секциям):
> component_id int(11)
> token_id int(11)
> action varchar(16)
> ip varchar(15)
> timestamp timestamp
Обращение происходит через HTTP/HTTPS, сам токен на доступ (token name) пересылается в заголовке POST/GET (второй вариант если API не представляет собой ничего ценного) вместе с названием компоненты/секции (component) и совершаемым действием над ней (action).
Со стороны сервера, соответственно, необходимо написать проверку на существование токена, проверку на доступ к компоненте/секции, проверку на деактивированный аккаунт, проверку на существование запрашиваемого действия (можно создать ещё одну таблицу вида api_component_actions с описанием всех возможных действий) + реализация самих действий, которые запросил клиент.
Примера выше достаточно, чтобы было более-менее приличное разделение доступа в дальнейшем, логирование, управление токенами с заморозкой как всего аккаунта (is_active), так и с вычленением только в определённой секции проекта (rules).
Исправление ThisNameWasFree, :
Простейший вариант на 4 таблицы:
api_components (функционал проекта делится на компоненты/секции, к которым в дальнейшем будете раздавать доступ):
> id int(11)
> name varchar(128)
api_rules (правила доступа для токенов - раздаёте на указанный токен определённые компоненты/секции):
> id int(11)
> token_id int(11)
> component_id int(11)
api_tokens (сами токены, в данном примере токен имеет длину 32 символа):
> id int(11)
> name varchar(32)
> is_active tinyint(1)
api_log (логи доступа к компонентам/секциям):
> component_id int(11)
> token_id int(11)
> action varchar(16)
> ip varchar(15)
> timestamp timestamp
Обращение происходит через HTTP/HTTPS, сам токен на доступ (token name) пересылается в заголовке POST/GET (второй вариант если API не представляет собой ничего ценного) вместе с названием компоненты/секции (component) и совершаемым действием над ней (action).
Со стороны сервера, соответственно, необходимо написать проверку на существование токена, проверку на доступ к компоненте/секции, проверку на деактивированный аккаунт, проверку на существование запрашиваемого действия (можно создать ещё одну таблицу вида api_component_actions с описанием всех) + реализация самих действий, которые запросил клиент.
Примера выше достаточно, чтобы было более-менее приличное разделение доступа в дальнейшем, логирование, управление токенами с заморозкой как всего аккаунта (is_active), так и с вычленением только в определённой секции проекта (rules).
Исправление ThisNameWasFree, :
Простейший вариант на 4 таблицы:
api_components (функционал проекта делится на компоненты/секции, к которым в дальнейшем будете раздавать доступ):
> id int(11)
> name varchar(128)
api_rules (правила доступа для токенов - раздаёте на указанный токен определённые компоненты/секции):
> id int(11)
> token_id int(11)
> component_id int(11)
api_tokens (сами токены, в данном примере токен имеет длину 32 символа):
> id int(11)
> name varchar(32)
> is_active tinyint(1)
api_log (логи доступа к компонентам/секциям):
> component_id int(11)
> token_id int(11)
> action varchar(16)
> ip varchar(15)
> timestamp timestamp
Обращение происходит через HTTP/HTTPS, сам токен на доступ (token name) пересылается в заголовке POST/GET (второй вариант если API не представляет собой ничего ценного) вместе с названием компоненты/секции (component) и совершаемым действием над ней (action).
Примера выше достаточно, чтобы было более-менее приличное разделение доступа в дальнейшем, логирование, управление токенами с заморозкой как всего аккаунта (is_active), так и с вычленением только в определённой секции проекта (rules).
Исходная версия ThisNameWasFree, :
Простейший вариант на 4 таблицы:
api_components (функционал проекта делится на компоненты/секции, к которым в дальнейшем будете раздавать доступ):
> id int(11)
> name varchar(128)
api_rules (правила доступа для токенов - раздаёте на указанный токен определённые компоненты/секции):
> id int(11)
> token_id int(11)
> component_id int(11)
api_tokens (сами токены, в данном примере токен имеет длину 32 символа):
> id int(11)
> name varchar(32)
> is_active tinyint(1)
api_log (логи доступа к компонентам/секциям):
> component_id int(11)
> token_id int(11)
> action varchar(16)
> ip varchar(15)
> timestamp timestamp
Обращение происходит через HTTP/HTTPS, сам токен на доступ (token name) пересылается в заголовке POST/GET (второй вариант если API не представляет собой ничего ценного) вместе с названием компоненты/секции (component) и совершаемым действием над ней (action).
Примера выше достаточно, чтобы было более-менее приличное разделение, логирование, управление токенами по активности (is_active), так и по доступам только в определённые секции проекта (components).