Интовый ID приятнее использовать в качестве `foreign key`, по крайней мере мне.
Например `name`ы в одной из таблиц могут быть такого вида: Cisco CIVS-IPC-6000P Hikvision DS-2CD8153F-E v1 Hikvision DS-2CD8153F-E v2
и т.д.
Делать ссылки по текстовому полю было бы куда сложнее, даже при наличии каскада.
Плюс `name` редактируемое поле, в этом случае нужно было бы передавать old_name на бэкенд при редактировании из консоли чтобы обновить объект.
Ну и в API проще передать и завалидировать число нежели "текст" как минимум при методах get, delete, copy.
Роман: Спасибо! Я как раз предлагаю сделать, как вы написали, это коллеги мои перестраховщики)
На сколько я понял, Вы имеете самое непосредственное отношение Удостоверяющему Центру. Не подскажете, какой софт лучше использовать в качестве ocsp responder?
Laroux спасибо Вам большое за ответ! Более профессионального ответа, я и ожидать не мог. Теперь все встало на свои места.
Я забыл от том факте, что реквесты от дочерних УЦ подписываются Корневым УЦ и собственно Корневой УЦ устанавливает свои ссылки на crl и ocsp а не на оборот.
Что касается второй части вопроса. Сейчас есть один УЦ который выдает "клиентские лицензии", то есть просто клиентские сертификаты. Есть программа для Windows, при установке она добавляет в хранилище арма сертификат УЦ. Далее клиент получает файл лицензии (p12), скармливает его программе - программа проверяя подпись ключа активирует программу. (В программе хардкодом вшита хэш сумма сертификата УЦ. Таким образом мы "как-бы" удостоверились что сертификат УЦ по которому происходит проверка наш.) Далее программа обращается к https серверу на котором включена проверка клиентских сертификатов и прикладывает свою клинтскую лицензию. Если проверка прошла успешно, сервер отдает некий контент для арма.
Теперь если переделать схему, на ту что я описал выше, получается что сертификат УЦ становится бандлом который будет содержать как CompanyName Project 2 CA так и Company Name Root CA и проверка лицензии будет происходить по нему.
Соответственно, было интересно, что будет если программе скормить сертификат выданный CompanyName Security CA (который так же в свою очередь подписан Company Name Root CA). Можно ли как то обойти проверку, допустив тот факт что админ выдал клинту сертификат выпущенный CompanyName Security CA а клиент установил в систему бандл CompanyName Security CA.
P.S. Как вариант, была идея добавлять в лицензии выдаваемые CompanyName Project 2 CA в качестве дополнительно oid некую хэш сумму (скажем serial_number + secret).
Но я не вижу в этом большого смыла т.к. секрет будет в любом случае вшит в программу а со стороны сервера придется пробрасывать параметры dn до движка и делать проверку программно. Не красиво как-то получается.
Спасибо за ответ. В данный момент 3-ий вариант является у меня основным.
Остается малая часть списка которая будет исключать всякие robots.txt crossdomain.xml и.т.
Так же рассматриваю вариант запретить точки в логинах, тогда эта проблема будет решена сама-собой. Но это не комильфо как мне кажется.
Интересно узнать мировую практику, на сколько часто на больших проектах в логинах разрешается точка.
Спасибо за ответ. Да, эти все варианты я понимаю, и скорее все придется воспользоваться одним из них, но пока буду думать еще, как реализовать такую схему.
Foo Bar: Я рассматривал вариант с хранением json'а или списка id через запятую, но отказался именно по причине ивалидности удаленных id. В данный момент разрабатывается прототип, по этому база пока MySQL. Там кстати тоже есть поддержка JSON начиная с версии 5.7. В данный момент использую свой же вышеописанный вариант.
Спасибо за комментарий!
Я знаю про все готовые решения для DigitalOcean, но мне из всего функционала нужно только 3 метода. Мне это решение не подходит. Здесь обсуждается проблема CURL, к DigitalOcean у меня нет претензий.
