Всем привет, есть проблема: разворачиваю проект на локалке, запускаю миграции - в ответ мне говорит, что указанной таблицы не существует.
Копаемся в коде, выясняем, что есть вот такая чудная конструкция
       try:
           return cls.objects.latest('id')
       except cls.DoesNotExist:
           return cls.objects.create()

есесна, все ломается на на try, т.к. таблицы еще нет.
Есть предложения, как обходить?

из общих соображений при проблеме миграций - можно попробовать изменить порядок их применения. В доках по джанге есть такой момент

Самое смекшное, что я прозрел, когда написал сообщение
       except ProgrammingError:
           settings = CmsSettings()
           return settings

И все, и похер - на время миграций не ломается, а потом не применится

там не совсем в порядке дело - оно использовало этот мтеод при любой операции, в том числе при миграции, так что все падало без шанса на миграцию

Подскажите пожалуйста раздел документации где описывается генерация ссылок по принципу {% url 'name' name=name %}

Спасибо

Товарищи, нужно прикрутить к джангокмс, djangocms_form, кто может помочь, за печеньки  само собой.

Прошу прощения и спасибо.

Интересно, а кто-нибудь изучал/пробовал блокчейн аутентификацию?
Такое есть вообще? =)

Ничего пока что не нашел в гугле
Интересно покопать в эту сторону, если аутентифицировать пользователя по классическим credentials, а после - блокчейном через те же headers можно добиться более высокого уровня секьюрности чем в JWT, про классическую авторизацию через кукис или DRF токен аутентификацию я вообще молчу

интересная темка IMO

какую-то наркоманию описал

Ребят, вопрос:
Есть необходимость в зависимости от текущего юзера работать с одноимённой базой данных(грубо говоря)
Можно ли через wsgi приложение ещё до эндпоинта доставать юзера и просто менять using=None  на using=request.username во всех методах класса Model (через наследование от неё и переопределение метода)?

@AlexDemianenko А зачем блокчейн? планируется распределённое хранение данных?

https://steemit.com/authentication/@mamont/besparolnaya-avtorizaciya-cherez-blokchein

вот человек описал эту схему, я нашел

Когда пользователь из браузера с сертификатом идёт на сайт, последний требует у браузера предъявить сертификат клиента.
Сервер, получив сертификат, вначале проверяет его подпись.
Сервер генерирует случайное число, шифрует его на публичном ключе, находящемся в предъявленном сертификате, и отправляет вашему браузеру. Это - одноразовый пароль соединения.
Браузер, имея файл с сертификатом и ключом, извлекает из него секретный ключ и расшифровывает пароль, посланный сервером. После этого браузер устанавливает безопасное https-соединение с сервером.
Сервер, убедившись в том, что клиент владеет корректным секретным ключом, производит проверку информации сертификата через блокчейн. Для этого он извлекает из сертификата серийный номер, и выполняет поиск по этому серийному номеру. После этого сервер вычисляет контрольную сумму только что полученного сертификата и убеждается в том, что предъявленный сертификат с соответствующим серийным номером – то же самый, который участвовал в регистрации.

я бы не торопился с выводами :)

Выглядит настолько костыльно, что есть смысл делать только из интереса)

Nikolay А как иначе можно реализовать задачу?
везде тыкать using?

А зачем блокчейн? Ты можешь по подписи пускать и всего

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

это если вот совсем в 2 словах