ValdikSS, не знал, что TLS с клиентскими сертификатами имеет какое-то специальное название, ок.
Логика подсказывает, что к обычной схеме ещё должна добавиться проверка клиентского серта, а всё остальное как обычно.
Maga Izdaga, предположу что из-за того что файл с секретами сравнительно маленький и никаких проблем передать через кастомный протокол нет, а кода может быть достаточно много - его легче будет передать через git.
В принципе никогда об этом не задумывался, тк не вижу в этом какого-то большого неудобства.
PS: сам хероку не пользовался никогда. Вернее пользовался только для деплоя docker-контейнера, который аналогично нужно заранее в docker-репу загрузить.
Сергей Кузнецов, и раз мы пришли к PAT, то в чём принципиальное удобство? Его же точно также придётся выпустить на гитхабе и скопировать на локальный комп - путь как с ключами, только в обратную сторону.
А один и тот же ключ можно успешно использовать сразу для всех репозиториев, а не только для гитхаба.
Сергей Кузнецов, зато при изменении пароля всё остаётся работать, не нужно мучаться с двухфакторкой
+ он никогда не протухает
+ прекрасно работает в любой среде, а если аутентифицироваться из сырого терминала без GUI, то шагов по входу с паролем и двухфакторкой будет больше.
Мне кажется, что спор достаточно глупый - всё равно все останутся при своём.
сергей кузьмин, наоборот очень удобно. Один раз ввёл в консоли ssh-keygen, закинул публичный ключ на гитхаб, и у тебя теперь никогда не протухающая аутентификация без необходимости вводить каждый раз пароль от учётки
это задача нахождения экстремума (минимума или максимума) целевой функции в некоторой области конечномерного векторного пространства, ограниченной набором линейных и/или нелинейных равенств и/или неравенств.
Собственно те задачи, которые под это определение не подпадают, те и не получится решить оптимизацией.
Что значит "подписка закрывается"?
По какому принципу ограничение должно быть? Типа пользователь ввёл 11111 и его выкидывает со страницы без возможности исправить?
Или где-то на бэке должно сохраняться сколько он уже "потратил" слов и нельзя сделать новый заказ на большее количество слов, чем у него осталось в запасе?
Логика подсказывает, что к обычной схеме ещё должна добавиться проверка клиентского серта, а всё остальное как обычно.