Для выпуска сертификатов Let's Encrypt нужно подтверждение домена. Так как у нас сервера не доступны из интернет, то HTTP-challenge нам не доступен, поэтому используем DNS-challenge.
Как работает: запускается certbot, ему в параметрах передается manual-auth-hook - powershell скрипт, который ловит токен и публикует его в DNS через то самое API.
С той же статьей, например, комментарии к софтово-удаленной статье можно таким же образом софтово-удалить.
Если потом восстановить софтово-удаленную статью, то не получится отличить комментарии, которые софтово-удалены вместе со статьей от комментариев, которые софтово-удалены сами по себе по кнопке "удалить комментарий".
Расскажите про ваше "улучшение" по автоматическому закрытию обращений без рассмотрения и обратной связи по существу вопроса.
Мы получили большое количество запросов и, к сожалению , в данный момент не можем Вам ответить. Пожалуйста, воспользуйтесь, разделом «Помощь и поддержка» или попробуйте обратиться позже. Обращение закрыто
Такой подход чем-то напоминает старое доброе обивание порогов "мне только спросить", "вам в кабинет №хх" и т.п.
Я так и не смог осмысленно пообщаться в чате по своей проблеме в работе портала, а email на который можно один раз написать и ждать ответа (пусть и неделю) у вас в способах связи отсутствует...
CSRF атака не подразумевает знание пароля. В общем то, если знаешь пароль, то атака (как и защита от неё) уже не нужна. Посмотрите на Википедии описание этой атаки, она очень простая.
Ну я вот тоже верил Майкрософту.
Забанили мой персональный аккаунт, я потерял все данные которые были на OneDrive. Кому только не писал, даже ездил в офис российского представительства. Только один из специалистов какой-то из линий саппорта проболтался, что видит в тикете странный комментарий, что система заблокировала аккаунт, но они сами не понимают причины. Так и остался без данных и без аккаунта.
Пока не побывал в этой шкуре, когда тебя «посадили в каталажку, но почему сами не знают, но выпускать не положено» я даже представить себе не мог, что такое возможно.
а зачем это? если это все равно читают только программисты, разве у них возникают проблемы с переводом данных терминов?
Нет, конечно, с этими терминами проблем особых нет. Но как только разрешаешь переводить термины, такая чехарда начинается… я выше приводил пример про AccountSubreport. А главное… ну толку от того, что 5 полей из 10 будут названы по английски? Уж лучше всё по русски или всё по английски.
private DataTable БалансКопейкиDT;
/// <summary>
/// Подгружает в форму остатки и обороты в копейках.
/// Заполняются только рубли и валюта, итого заполняется отдельно.
/// </summary>
public void ЗагрузитьБалансВКопейках()
{
ДобавитьИнформацию("ЗагрузитьБалансВКопейках");
БалансКопейкиDT =
ASSql.ConnOper().ExecuteSpDt(
"[обязательная-отчетность].[Ф0409101 - баланс в копейках]",
"@ДатаНачало", ДатаНачало,
"@ДатаОкончание", ДатаОкончание,
"CommandTimeout", 600);
foreach (var DR in БалансКопейкиDT.RowsDR())
{
var Раздел = Разделы[(string)DR["Символ раздела"]];
var Счет = Раздел.Счета[(string)DR["Счет второго порядка"]];
var Валюта = (string)DR["Рубли-Валюта"];
var РублиВалюта =
Валюта.StrEq("Рубли") ? Счет.Рубли :
Валюта.StrEq("Валюта") ? Счет.Валюта :
throw new DevMistakeException($"Не умею работать с записями [Рубли-Валюта]='{Валюта}'");
РублиВалюта.Входящий.Копейки = (decimal)DR["Входящий"];
РублиВалюта.Дебет.Копейки = (decimal)DR["Дебет"];
РублиВалюта.Кредит.Копейки = (decimal)DR["Кредит"];
РублиВалюта.Исходящий.Копейки = (decimal)DR["Исходящий"];
foreach (var Значение in РублиВалюта)
{
Значение.Тысячи = Значение.КопейкиВТысячиПоМатематике;
}
}
if (БалансКопейкиDT.RowsDR().IsEmpty())
{
ДобавитьОшибку("Странно, но не удалось загрузить баланс в копейках");
}
}
а почему у вас сотрудники-не программисты видят классы, методы, переменные и таблицы?
А я не говорил, что сотрудники-не программисты видят классы. Под сотрудниками я имел в виду как раз программистов. И эти программисты помимо как с друг другом, общаются с бизнес-пользователями тоже на русском языке, а не на английском.
может иногда привести к очень и очень неожиданным и крайне неприятным последствиям, и учитывая что в отрасли очень мало кто так делает… расследование подобных глюков превратится в очень увлекательный квест. по этому крайне и крайне не рекомендуется так делать
Мы так уже лет 15 делаем. Если и были какие-либо мелкие проблемы, то они просто несравнимы с N человек * 15 человеко-лет недо-переводов с русского на английский и обратно.
а ещё помнб геморрой с переключением локали везде где Oracle DB клиент стоит, чтобы упасибоже в неправильной кодировке туда чтото не улетело
Если вы таблицы со столбцами ещё можете назвать латиницей, то данные у вас в любом случае полетят в неправильной кодировке, так что проблема кодировки не связана с языком на котором называются объекты
К раскладкам привыкаешь… за неделю, может быть две.
К различным недо-переводам терминологии привыкнуть не возможно т.к. любой термин переводится разными сотрудниками по разному и в итоге никто ничего не понимает. С тем же успехом можно называть объекты A, B, C,… какая разница уже :)
Программируем на C#. У нас запрещено что-либо переводить как с русского на англйский, так с английского на русский.
Всё — классы, методы, переменные, таблицы, столбцы, всё в 99% случаев на русском языке т.к. работаем в России с русско-говорящими сотрудниками и не хотим тратить их время на перевод с русского на английский и далее в обратную сторону когда кто-то другой вносит изменения в тот же код.
Исключение только для интеграции с внешними системами — если разработчики этих внешних систем назвали свои объекты/аттрибуты по английски, то в точности копируем их наименование, таким образом тоже исключаем трату ресурсов на перевод на русский и дальше в обратную сторону, когда во внешней системе что-то изменилось и нужно внести изменения в код.
Работаем в банковской сфере, в которой, казалось бы, не должно быть никаких проблем с международной терминологией. Однако, никто с ходу не знает как перевести «счет подотчета» (даже с использованием Google Translate), а когда смотришь на то, что разработчик назвал это AccountSubreport, хочется плакать.
Если вы делаете в одиночку что-то для «заказчика», то, конечно, ему не важно, хоть на Delphi можно делать.
Когда же ищешь людей в команду, то все сложнее и сложнее искать их на устаревшие технологии.
Что такого в новых версиях? Возможности языка, например, новые появляются. Какие-то готовые решения со временем перестают появляться для старого или появляются с задержкой или их выбор не велик и не радует качеством.
А архитектура, уж извините, организована как организована… не бывает архитектур, приспособленных к любым поворотам в которые их может занести. Или бывает, но долго, дорого и никому не нужно.
На самом деле, меня больше интересовал практический вопрос, что не полетело в grpc, т.к. сам на него поглядываю как на потенциальную замену wcf.
Планируете ли на что-нибудь мигрировать в свете отсутствия wcf в актуальных версиях .net?
Расскажите про опыт grpc, это актуальный вопрос для тех кто думает на что менять wcf.
Реальность такова, что нельзя складывать яйца в одну корзину. У всех бывают сбои, все допускают ошибки. Нельзя пользоваться одним интернет-провайдером, нельзя пользоваться одним мобильным оператором, нельзя пользоваться одним облаком.
Сам до недавнего времени держал все данные в OneDrive. Вот уже 2 месяца как Майкрософт заблокировал мою учётку и не отвечает на запросы. То же может случится и с любым другим облаком, в том числе корпоративным, уверяю, во всех политиках использования написано о том, что провайдер имеет на это право.
Все думают, что их это не коснётся. Я тоже так думал, я обыкновенный пользователь, ничего противозаконного не делал, но это всё никого не волнует — должен держать вторую копию или делать регулярные бэкапы, так и написано в условиях использования.
Если машина с certbot доступна извне, то мне было бы достаточно http challenge. Если же она не доступна извне, то ваш вариант тоже не подойдет.
Для выпуска сертификатов Let's Encrypt нужно подтверждение домена. Так как у нас сервера не доступны из интернет, то HTTP-challenge нам не доступен, поэтому используем DNS-challenge.
Как работает: запускается certbot, ему в параметрах передается manual-auth-hook - powershell скрипт, который ловит токен и публикует его в DNS через то самое API.
Выложил полные скрипты на GitHub, пользуйтесь если нужно: https://github.com/archimed7592/certbot-1cloud
Используем 1cloud так как они дают API для управления зоной. Нам API необходим для подтверждения сертификатов let’s encrypt.
Конечно, нужен. Лишь подтверждение тому, что у задачи отсутствует чисто-техническое решение, как вы верно заметили в своём изначальном комментарии.
Если потом восстановить софтово-удаленную статью, то не получится отличить комментарии, которые софтово-удалены вместе со статьей от комментариев, которые софтово-удалены сами по себе по кнопке "удалить комментарий".
Расскажите про ваше "улучшение" по автоматическому закрытию обращений без рассмотрения и обратной связи по существу вопроса.
Такой подход чем-то напоминает старое доброе обивание порогов "мне только спросить", "вам в кабинет №хх" и т.п.
Я так и не смог осмысленно пообщаться в чате по своей проблеме в работе портала, а email на который можно один раз написать и ждать ответа (пусть и неделю) у вас в способах связи отсутствует...
CSRF атака не подразумевает знание пароля. В общем то, если знаешь пароль, то атака (как и защита от неё) уже не нужна. Посмотрите на Википедии описание этой атаки, она очень простая.
Ну я вот тоже верил Майкрософту.
Забанили мой персональный аккаунт, я потерял все данные которые были на OneDrive. Кому только не писал, даже ездил в офис российского представительства. Только один из специалистов какой-то из линий саппорта проболтался, что видит в тикете странный комментарий, что система заблокировала аккаунт, но они сами не понимают причины. Так и остался без данных и без аккаунта.
Пока не побывал в этой шкуре, когда тебя «посадили в каталажку, но почему сами не знают, но выпускать не положено» я даже представить себе не мог, что такое возможно.
Нет, конечно, с этими терминами проблем особых нет. Но как только разрешаешь переводить термины, такая чехарда начинается… я выше приводил пример про AccountSubreport. А главное… ну толку от того, что 5 полей из 10 будут названы по английски? Уж лучше всё по русски или всё по английски.
Что именно вас тут убивает? :)
А я не говорил, что сотрудники-не программисты видят классы. Под сотрудниками я имел в виду как раз программистов. И эти программисты помимо как с друг другом, общаются с бизнес-пользователями тоже на русском языке, а не на английском.
Мы так уже лет 15 делаем. Если и были какие-либо мелкие проблемы, то они просто несравнимы с N человек * 15 человеко-лет недо-переводов с русского на английский и обратно.
Если вы таблицы со столбцами ещё можете назвать латиницей, то данные у вас в любом случае полетят в неправильной кодировке, так что проблема кодировки не связана с языком на котором называются объекты
К различным недо-переводам терминологии привыкнуть не возможно т.к. любой термин переводится разными сотрудниками по разному и в итоге никто ничего не понимает. С тем же успехом можно называть объекты A, B, C,… какая разница уже :)
Всё — классы, методы, переменные, таблицы, столбцы, всё в 99% случаев на русском языке т.к. работаем в России с русско-говорящими сотрудниками и не хотим тратить их время на перевод с русского на английский и далее в обратную сторону когда кто-то другой вносит изменения в тот же код.
Исключение только для интеграции с внешними системами — если разработчики этих внешних систем назвали свои объекты/аттрибуты по английски, то в точности копируем их наименование, таким образом тоже исключаем трату ресурсов на перевод на русский и дальше в обратную сторону, когда во внешней системе что-то изменилось и нужно внести изменения в код.
Работаем в банковской сфере, в которой, казалось бы, не должно быть никаких проблем с международной терминологией. Однако, никто с ходу не знает как перевести «счет подотчета» (даже с использованием Google Translate), а когда смотришь на то, что разработчик назвал это AccountSubreport, хочется плакать.
Не приемлемым, а одинаковым. Это нужно, чтобы злоумышленник не мог по времени ответа угадать — есть такой логин/email или нету.
P.S. в орининале:
Вы хотели сказать так-же сложно, как и в первые 2-3 месяца? :)
Если вы делаете в одиночку что-то для «заказчика», то, конечно, ему не важно, хоть на Delphi можно делать.
Когда же ищешь людей в команду, то все сложнее и сложнее искать их на устаревшие технологии.
Что такого в новых версиях? Возможности языка, например, новые появляются. Какие-то готовые решения со временем перестают появляться для старого или появляются с задержкой или их выбор не велик и не радует качеством.
А архитектура, уж извините, организована как организована… не бывает архитектур, приспособленных к любым поворотам в которые их может занести. Или бывает, но долго, дорого и никому не нужно.
На самом деле, меня больше интересовал практический вопрос, что не полетело в grpc, т.к. сам на него поглядываю как на потенциальную замену wcf.
Планируете ли на что-нибудь мигрировать в свете отсутствия wcf в актуальных версиях .net?
Расскажите про опыт grpc, это актуальный вопрос для тех кто думает на что менять wcf.
Буду признателен за ссылку на первоисточник в котором говорится, что 5.0 объединит fw4 и core3
Реальность такова, что нельзя складывать яйца в одну корзину. У всех бывают сбои, все допускают ошибки. Нельзя пользоваться одним интернет-провайдером, нельзя пользоваться одним мобильным оператором, нельзя пользоваться одним облаком.
Сам до недавнего времени держал все данные в OneDrive. Вот уже 2 месяца как Майкрософт заблокировал мою учётку и не отвечает на запросы. То же может случится и с любым другим облаком, в том числе корпоративным, уверяю, во всех политиках использования написано о том, что провайдер имеет на это право.
Все думают, что их это не коснётся. Я тоже так думал, я обыкновенный пользователь, ничего противозаконного не делал, но это всё никого не волнует — должен держать вторую копию или делать регулярные бэкапы, так и написано в условиях использования.