Несколько видов регистрации/входа на сайте | Forum

5 June 2016, 13:05

Posts: 18

5 June 2016, 13:05

Posts: 18

Ребят, привет! Подскажите пожалуйста идею, как правильней реализовать функционал. Есть 2 вида регистрации/входа пользователей на сайт(е):

1. Назовем его(ее) "обычная(ый)" (т. е. через логин(эмэйл), пароль ). Для этой категории юзеров будет ограниченный функционал ресурса;

2. Через специальный файл(к примеру файл *.dat с информацией о пользователе; а именно пользователя характеризует какой-то uuid, пропущенный через хэш-функцию, например; т. е. уже не запишешь это в username, а нужна отдельная таблица для этого атрибута + еще много другой информации о пользователе). А для этих товарищей доступно все на сайте.

Что для этого требуется?

1. Отказаться от стандартной регистрации Джанги(тут возникли проблемы с бэкэндом; я задавал вопрос на форуме уже http://djbook.ru/forum/topic/4631/);

2. Написать свои формы для рег/входа (тут понятно);

3. Написать свои модели(как указать свои 2 модели в settings.py???);

4. Написать свои вьюшки и бэкэнды;

Вопросы:

1. Нужно ли выделять 2 таблицы под разные категории пользователей?

2. Как указать "пермишнсы" для юзеров; к примеру одни пользователи могут кликать по какой-то абстрактной кнопке, а другие нет?

3. На каком этапе определять, какой юзер "стучится" на сайт; на фронте или не бэке?

ЗЫ: Сразу скажу, что вопросы задаются не из ряда "решите за меня". Я не преследую эту цель. Мне важны дельные советы, ссылки, ссорцы где можно покопаться, какие-то идеи и соображения из личного опыта хотя бы по некоторым вопросам с которыми Вам приходилось сталкиваться;

ЗЫЗЫ: Джангой и питоном совсем недавно заинтересовался и занялся, поэтому возникают вопросы.

Updated 5 June 2016, 13:15 by Jaroslav.

Answer | 0

5 June 2016, 17:01

N.E.M

Posts: 1262

5 June 2016, 17:01

N.E.M

Posts: 1262

если проще, то нужна авторизация по токену?

Решается просто.

При создании пользователя создаёте ему токен по нужному алгоритму, записываете в поле профиля. Правда же, первое, что вы сделали в проекте – создали кастомного юзера?
Создаёте вьюху, в которой выбираете юзера по токену;
не забываем про https.

Answer | 0

5 June 2016, 18:21

Jaroslav

Posts: 18

5 June 2016, 18:21

Jaroslav

Posts: 18

если проще, то нужна авторизация по токену?

Решается просто.

При создании пользователя создаёте ему токен по нужному алгоритму, записываете в поле профиля. Правда же, первое, что вы сделали в проекте – создали кастомного юзера?

Создаёте вьюху, в которой выбираете юзера по токену;

не забываем про https.

Спасибо большое за ответ! Но у меня еще есть вопросы.

1. Можно ли вообще в таком случае сделать 2 поля во всего одной таблице accounts? Поле id(autoinc) и поле token(а сюда пишем всю инфу по пользователю предварительно пропустив через соответствующий алгоритм; и не важно какой у нас юзер, который зарегался по логину и паролю либо через спецфайл; все равно на выходе мы получаем массив данных).

2. Каким способом после производить выборку пользователя? Поле token сделать ключевым?

3. Кастомного юзера я создал сразу же, это верно! Регистрация работает, а вот логирование нет. Ругается на атрибут user.backend. Как это поправить пока вопрос не решенный.

Answer | 0

5 June 2016, 18:36

N.E.M

Posts: 1262

5 June 2016, 18:36

N.E.M

Posts: 1262

вот про ругань на бэкенд непонятно. Зачем его вообще трогать? Чем больше стандартного, тем лучше. Стандартный бэкенд тут годится. Переопределять его в вашем случае незачем.

дополнительных таблиц никаких не нужно. Нужна кастомная модель юзера. И в этой модели поле под токен. Этого достаточно.

Поле токена необязательно делать ключевым. Его можно индексировать, да, особенно если проект нагруженный.

Для авторизации по токену нужно слать http-запрос например с токеном в заголовке. И вообще, как предполагается такую авторизацию использовать? Это для мобильных приложений? Можно тогда и вовсе миддлварь написать, где будет заголовок читаться и авторизовываться, если юзер с названным токеном существует.

Answer | 0

5 June 2016, 18:37 N.E.M Posts: 1262	5 June 2016, 18:37 N.E.M Posts: 1262 а знаете что? На большую часть задач есть уже готовые решения. Посмотрите вот сюда: http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication
	Answer \| 0

5 June 2016, 19:53

Jaroslav

Posts: 18

5 June 2016, 19:53

Jaroslav

Posts: 18

Спасибо большое за ответы! На статью натыкался после вашего совета про токены. Посмотрел бегло, но сейчас более подробно изучу! Кастомный бэк уберу, верну стандартный, посмотрю что получится.

Нет, это не для мобильных приложений. Вэб ресурс, использоваться будет исключительно на ПК(ну пока во всяком случае).

Answer | 0

5 June 2016, 20:02

N.E.M

Posts: 1262

5 June 2016, 20:02

N.E.M

Posts: 1262

да тут не так важно, для чего именно. Смысл в том, что некое стороннее приложение (не браузер) будет авторизовываться другим способом. Верно я понимаю?

В общем, нужна вьюха или миддлварь. В этой сущности читаем токен, как бы он ни был передан. По токену выбираем юзера. Затем авторизовываем его: http://djbook.ru/rel1.9/topics/auth/default.html#how-to-log-a-user-in Затем делаем что нужно уже имея авторизованного пользователя.

Answer | 0

5 June 2016, 23:08

TheFool

Posts: 182
Location: Минск

5 June 2016, 23:08

TheFool

Posts: 182
Location: Минск

Немного дополню.

Как указать "пермишнсы" для юзеров; к примеру одни пользователи могут кликать по какой-то абстрактной кнопке, а другие нет?

И в Django и в DRF(если вы будтете его использовать) есть разделы permissions. Ссылочка на django и DRF, если не нашли.

На каком этапе определять, какой юзер "стучится" на сайт; на фронте или не бэке?

Определенно на бэк энде. Все проверки на фронте можно обойти.

Updated 5 June 2016, 23:10 by TheFool.

Answer | 1