Не зря же покупают именные сертификаты, браузеры и имя компании пишут в строке

зря, это обычный распил инвесторского бабла

а вот реальной потребности в OV/EV ради валидации компании нет, клиенты это не понимают

это работает именно с этой позиции, просто как некий маркетинговый инструмент, не более того

+

именно так

Раз покупают значит нужно и с маркетинговой точки зрения в том числе

Расширенный сертификат показывает что центр сертификации проверил организацию

Расширенный сертификат показывает что центр сертификации проверил организацию

что проверил? ? важной инфы нет и не проверяется.

Телефон знаю проверяют точно, звонят и т.д.

https://www.gogetssl.com/extended-validation/comodo-instantssl-ev/

вот самый дешёвый EV

это элементарно проверяется по любой фирме на раз

телефон voip вообще бесплатно получить можно

вот самый дешёвый EV

47 баксов/год

47 баксов/год

демпингуют :) кстати они (многие серт центры) и проверяют спустя рукава все

вообще, да, раньше это было раза в 3 дороже, цены упали

для организации имеет смысл сделать такое

но если ты просто ИП или частное лицо - EV не дадут

то есть если у нас там малый бизнес и всё оформлено на ИП, он(-а) в любом случае не сможет получить EV, значит, самый разумный вариант - Lets Encrypt

добрый день. задача: одна из записей в модели должна быть главной, остальные - второстепенными. есть ли какой-нибудь инструмент, позволяющий это сделать с меньшими телодвижениями? придумал такой вариант: class ModelName(models.Model): name = models.CharField(max_length=255) base = models.BooleanField(default=False) и выкидывать в админке и в методе save() исключения, если ModelName.objects.get(base=True)

Раз покупают значит нужно и с маркетинговой точки зрения в том числе

ну, богатые бизнесмены тоже ездят на дорогих машинах

EV сертификат - как дорогая машина

важно поддерживать уровень

добрый день. задача: одна из записей в модели должна быть главной, остальные - второстепенными. есть ли какой-нибудь инструмент, позволяющий это сделать с меньшими телодвижениями? придумал такой вариант: class ModelName(models.Model): name = models.CharField(max_length=255) base = models.BooleanField(default=False) и выкидывать в админке и в методе save() исключения, если ModelName.objects.get(base=True)

ну да, как то так

EV сертификат - как дорогая машина

ну, уже не дорогая)

$47/год

добрый день. задача: одна из записей в модели должна быть главной, остальные - второстепенными. есть ли какой-нибудь инструмент, позволяющий это сделать с меньшими телодвижениями? придумал такой вариант: class ModelName(models.Model): name = models.CharField(max_length=255) base = models.BooleanField(default=False) и выкидывать в админке и в методе save() исключения, если ModelName.objects.get(base=True)

не очень понятно описание задачи

не очень понятно описание задачи

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

BooleanField выглядит правильным решением

ну, и индекс, наверное, нужно повесить

как вариант добавить поле BooleanField + добавить индекс unique_together = ('товар','флаг')

а нет

unique_together так нельзя

я добавил в clean метод проверку и в админке переопределил get_readonly_fields

я добавил в clean метод проверку и в админке переопределил get_readonly_fields

clean модели

в общем, зависит от структуры базы данных, можно сделать отдельную сущность Товары, отдельную сущность Фото, между ними М:Н связь, и отдельное поле main_photo, это FK в Товарах к Фото

ну, ещё вариант через BooleanField, да, тогда в методе save() нужно обновлять другие фото и ставить там False в аналогичное поле у других фоток

но мне больше нравится через FK

но мне больше нравится через FK

спасибо)) да, мне тоже) но не получится(

ну тогда проверка в save()

если этот True, то ищем другие фото и сбрасываем там в False

ну тогда проверка в save()

а почему не в clean()?

лучше всего делать отдельную сущность

в общем, зависит от структуры базы данных, можно сделать отдельную сущность Товары, отдельную сущность Фото, между ними М:Н связь, и отдельное поле main_photo, это FK в Товарах к Фото

как описанно тут

и проставлять CASCADE

а почему не в clean()?

но это же просто валидация? то есть будет риск того, что мы у других сбросим, а этому ещё не поставим

и какое-то время у нас вообще главной фотки не будет для этого товара, верно?

всё верно, переделаю.. спасибо)

но самый лучший вариант с M:H + 1:M для дефолтной фотки

раз уж речь пошла про сертификаты есть ли разница между бесплатным (допустим lets encrypt) и платным (допустим startssl/gogetssl) для ssl pinning'а в мобильном приложении?

раз уж речь пошла про сертификаты есть ли разница между бесплатным (допустим lets encrypt) и платным (допустим startssl/gogetssl) для ssl pinning'а в мобильном приложении?

нет

но у LE сертификаты живут 3 месяца

Но их же можно по крону обновлять?!

конечно, нужно

просто с ssl pinning'ом придется еще и приложение обновлять

Спам спам спам

Глупый вопрос - возможно ли разделить models на несколько файлов?) Или папку сделать :D

Сколько занимаюсь, ни разу не приходилось

Можно, но не нужно

Можно, но не нужно

Если у меня 30 моделей и еще менеджеры?

сделать модуль и в ините заимпортить все что нужно?

хз, никогда такого не делал

from .models2 import * и нет проблем, но некрасиво

ссылаться на импортируемы модели можно будет и из models

ERROR: S client not available

А вьюшки кто нить сплиттил?

from .models2 import * и нет проблем, но некрасиво

Некрасиво да

Мб есть dry путь

я сплитил и вьюшки и модели и не стесняюсь этого :)

вьюшки еще проще сплитить, ведь views это лишь название ты можешь их пихать куда угодно

лучше придерживаться гуглостиля в коде, он хороший

но я просто сделал папку models а файлик models.py удалил и все работает нормально, и админка и сайт и консольные команды

from .models2 import * у меня нет

так можно всё делать

from .models2 import * у меня нет

Модуль сделал? Или как?

И так и так можно, не важно

Интересно как тру

Можно и templates в static/js/ класть

Никак. Я settings делаю отдельной папкой, а кто-то все в один файл пихает. Кому как нравится

Никак. Я settings делаю отдельной папкой, а кто-то все в один файл пихает. Кому как нравится

Отдельной папкой это известный тру способ

Спасибо большое )

Отдельной папкой это известный тру способ

Так а какая разница settings милм model

Никакой наверное

Спасибо за ответы, буду траить

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

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

А если приложения reusable должны быть то никак иначе

Можно папкой, да, когда моделей много А менеджеры можно в managers.py вытащить

Да, конечно, если планируется использовать еще, то никак иначе, но когда делают сайт и создают приложения faq, feedback и т.д. а внутрь пихают шаблоны, это ужас для бедных сеошников и прочих умельцев, которые любят статику править по живому

Да, конечно, если планируется использовать еще, то никак иначе, но когда делают сайт и создают приложения faq, feedback и т.д. а внутрь пихают шаблоны, это ужас для бедных сеошников и прочих умельцев, которые любят статику править по живому

если микросервисная архитектура - то у каждого сервиса свои шаблоны иметь - правильно

Да, конечно, если планируется использовать еще, то никак иначе, но когда делают сайт и создают приложения faq, feedback и т.д. а внутрь пихают шаблоны, это ужас для бедных сеошников и прочих умельцев, которые любят статику править по живому

Ну это ведь не проблема правильной структуры приложений нашего фреймворка, да?

если микросервисная архитектура - то у каждого сервиса свои шаблоны иметь - правильно

Есть случаи когда это оправдано, если когда не оправдано. Скажу так, в большинстве случаев нет.

Ну это ведь не проблема правильной структуры приложений нашего фреймворка, да?

Это как вот с разделением model правильно и так и так.

А если приложения reusable должны быть то никак иначе

у вас реюзабл приложения?

у вас реюзабл приложения?

Иногда да, иногда нет

ну, вот допустим, в проекте есть функционал относяйщийся к биллингу и есть функционал относяйщийся к соц. сети