BK
Типа у каждой роли будут свои эндпоинты api к которым он сможет обращаться
Size: a a a
2020 August 09
BK
с моб приложения
N
@Nire1 спасибо.
Может еще тогда подскажешь за 1 момент)
У меня есть 2 роли
Авторизация проходит стандартно, ввёл номер, получил код зашёл.
Так вот для определения под какой ролью этот юзер который авторизовался, я так понял мне нужно копаться в django.permissions?
Может еще тогда подскажешь за 1 момент)
У меня есть 2 роли
Авторизация проходит стандартно, ввёл номер, получил код зашёл.
Так вот для определения под какой ролью этот юзер который авторизовался, я так понял мне нужно копаться в django.permissions?
Добавь в юзере поле is_ktoto
N
Если ролей мало
BK
Понял, спасибо
D
Типа у каждой роли будут свои эндпоинты api к которым он сможет обращаться
можно определять прямо по куке, что за пользователь. Я обычно создаю дополнительную модель к юзеру, где описываются дополнительые свойства, например другая роль
D
тебе бы бан выписать. Ты за кого здесь всех считаешь?
BK
можно определять прямо по куке, что за пользователь. Я обычно создаю дополнительную модель к юзеру, где описываются дополнительые свойства, например другая роль
Окей, вариант с доп моделью.
Получается потом на эндпоинты в коде нужно будет навешивать какой тип юзеров может стучать к этому апи?
Получается потом на эндпоинты в коде нужно будет навешивать какой тип юзеров может стучать к этому апи?
D
Окей, вариант с доп моделью.
Получается потом на эндпоинты в коде нужно будет навешивать какой тип юзеров может стучать к этому апи?
Получается потом на эндпоинты в коде нужно будет навешивать какой тип юзеров может стучать к этому апи?
Здесь всё зависит от задачи. Очевидно, что некоторые точки будут совершенно другими. Например какой-то закрытый доступ для обычных пользователей. Для части информации можно добавить разный кверисет/сериалайзер в зависимости от пользователя. В эту сторону я бы и смотрел. Например обычный пользователь видет записи без поля foo, а особенный пользователь с этим полем. Переопределяешь сериалайзер во вьюхе и в путь
BK
Здесь всё зависит от задачи. Очевидно, что некоторые точки будут совершенно другими. Например какой-то закрытый доступ для обычных пользователей. Для части информации можно добавить разный кверисет/сериалайзер в зависимости от пользователя. В эту сторону я бы и смотрел. Например обычный пользователь видет записи без поля foo, а особенный пользователь с этим полем. Переопределяешь сериалайзер во вьюхе и в путь
Ну вроде все понятно) спасибо за хелп
D
Ну вроде все понятно) спасибо за хелп
добавлю к ответу @Nire1, что поле is_someone хороший вариант, однако как и в случае с полями м2м это скользкая дорожка. Всегда может понадобиться как-то расширить модель особенного пользователя, или как в случае с м2м добавить дополнительные поля к промежуточной таблице. И если гипотетически такая ситуация возможна, то лучше, мне кажется, заранее перестраховаться
BK
Ещё кстати по DRF хотел спросить)
API решили писать используя django + drf само моб приложение будет разрабатываться на Unity, может есть какие-то подводные камни? Или сильные минусы в такой связке?
Или же тут без разницы на чём backend будет
API решили писать используя django + drf само моб приложение будет разрабатываться на Unity, может есть какие-то подводные камни? Или сильные минусы в такой связке?
Или же тут без разницы на чём backend будет
N
Ещё кстати по DRF хотел спросить)
API решили писать используя django + drf само моб приложение будет разрабатываться на Unity, может есть какие-то подводные камни? Или сильные минусы в такой связке?
Или же тут без разницы на чём backend будет
API решили писать используя django + drf само моб приложение будет разрабатываться на Unity, может есть какие-то подводные камни? Или сильные минусы в такой связке?
Или же тут без разницы на чём backend будет
Да, типы данных хорошо надо знать и в питоне, и в шарпе. Но это не камень, а просто требование.
N
У меня была с датой и кодировкой проблема постоянно
D
Ещё кстати по DRF хотел спросить)
API решили писать используя django + drf само моб приложение будет разрабатываться на Unity, может есть какие-то подводные камни? Или сильные минусы в такой связке?
Или же тут без разницы на чём backend будет
API решили писать используя django + drf само моб приложение будет разрабатываться на Unity, может есть какие-то подводные камни? Или сильные минусы в такой связке?
Или же тут без разницы на чём backend будет
django + drf хороший, классический вариант. Сразу советую обратить внимание на drf_yasg для генерации документации
BK
django + drf хороший, классический вариант. Сразу советую обратить внимание на drf_yasg для генерации документации
Да, такое юзал
BK
Да, типы данных хорошо надо знать и в питоне, и в шарпе. Но это не камень, а просто требование.
В том плане, что на шарпе их нужно в правильном формате принять и обработать для аппликухи?
N
В том плане, что на шарпе их нужно в правильном формате принять и обработать для аппликухи?
Ну в шарпе и питоне по разному формат дат пишется
N
Ну вроде там надо просто конвертер написать, в этом сложности нет, но надо иметь ввиду
N
Мы забили и таймстампами обменивались и каждый конвертил потом как надо