Сходу лирическое отступление спецом для украинских читателей: злорадная мысль, первой пришедшая вам в голову, ошибочна. Несложно убедиться в том, что блог, странички которого вы в данный момент с интересом листаете, хостится на AWS, и - тому уже немало лет. Отсюда следует, что мне несложно добавить к своим платежам Амазону за бугор - еще и платежи Heroku, технически в этом нет проблем, невзирая ни на какие санкции. Но актуальный прайс Heroku я считаю для себя излишне дорогим, тем более, мне нужно всего только опубликовать в вебе два несложных rails-app, имеющих целью не то чтобы приносящую мне очевидный профит рекламу, но, скорее, собственное удовольствие.

Здесь, пожалуй, следует уточнить: бесплатный Heroku по-прежнему доступен для open source проектов, подробнее здесь. Но время от времени приходится запрашивать бесплатность заново, это хлопотно и неудобно.

Таким образом, прежде чем поднимать на AWS еще один инстанс спецом под Rails, пошел я тестировать недорогие шареды на российских хостингах. NetAngels, по ряду причин, не понравился сразу, на Locum.ru мои проекты провисели некоторое время. Расскажу о своих впечатлениях; не в целях нелепого злорадства, подобно моим землякам с Украины, но - чтобы другие, возможно, не наступили на те же грабли, что и я.

Отношения с саппортом изначально не заладились. Спервоначалу озадачила не самая критичная техническая проблема: ребутить приложения на NetAngels мне приходилось два раза, после одиночного ребута application не поднимался, демонстрируя в этом завидную стабильность. Когда, в ходе консультации с саппортом в рамках "технической поддержки", я услышал тезис о том, что какие-то неназванные gems в моем Gemfile "текут абсолютно точно" - при этом ни аргументации, ни названий джемов я не услышал, это было полностью голословное предположение, основанное на железобетонном "жалоб от других пользователей не было" - и практически сразу же от саппорта поступило иное предположение, "в ближайшее время мы, помимо, unicorn, предоставим возможность использовать puma, и эта проблема у вас должна исчезнуть" - на меня повеяло чем-то настолько хорошо знакомым по гребаной работе в IT, что данный кейс уже сам собой отложился в памяти.

Но редфлагом оказалась более серьезная техническая проблематика. Началось вот так (орфография саппорта здесь и далее сохранена полностью):

Я: 14 ноября 2023, 23:37
Включил force_ssl. И мгновенно вернулось "Can't verify CSRF token authenticity." На любой странице сайта, где есть форма отправки данных. Странно, до включения, даже при работе через https, этой проблемы не было. Any ideas?

support42: 15 ноября 2023, 11:41
На какой адрес у Вас происходит отправка POST-запроса? с формы
Так же Вы не отключили на Вашем сайте HSTS и теперь браузеры будут обращаться к Вашему сайту только по протоколу HTTPS. Данная опция кешируется браузерами по умолчанию на домен и все поддомены на 63072000 секунд (1 год)

support42: 15 ноября 2023, 12:31
Локально вероятно Вы тестировали сайт в development окружении. Под чем именно запускается приложение под puma или unicorn никак не влияет

Я: 15 ноября 2023, 12:34
А на Heroku тоже development mode, вы думаете?

support42: 15 ноября 2023, 12:47
Вполне возможно.
Проверьте как минимум что у Вас в layout присутствует как минимум  <%= csrf_meta_tag %>

Я: 15 ноября 2023, 12:57
Безграмотный совет. Разумеется, тэг присутствует во всех вьюхах, где есть формы. Это следует из моего описания выше.
Убедительная просьба: когда нет конкретики ответа, не присылать мне ссылку на ворох доков и/или SO; дескать, покопайся, узнаешь то, что даже я сам не знаю. Гуглить я умею, поверьте; в саппортах вот, правда,  не работал, но брендовые highload проекты в одиночку на себе тащил.
P.S. все проекты на Heroku по умолчанию запускаются в production. Запомните, пригодится на будущее. Ваше "возможно" в данном случае некорректность, являясь попыткой ввести в заблуждение.

В итоге автор данного отчета почел за благо забить на это все, сообразив, что задачка явно выходит за пределы уровня профессиональных спецификаций сотрудников хостинга Locum.ru. Тем не менее, спустя некоторое время трабла выплыла вновь: теперь, что логично, при включении force_ssl, обламывался логин devise.

Саппорт потребовал от меня полный reproduce, каковой и был ему аккуратно (ах, время, время!) предоставлен... спустя четыре дня кропотливой работы "отдела веб-разработки" Locum.ru (каким хером тут веб-разработка?) ребятишки вышли на связь, полные надежд ошеломить меня грандиозными результатами проделанного:

support: 19 июня 2024, 15:20
При включенной опции config.force_ssl = true
включается также проверка CSRF токенов.
У Вас возникает исключение:

===
I, [2024-06-19T14:11:14.096424 #56160]  INFO -- : [5baeac08-4601-4749-ae9e-e913f8789855]   Parameters: {"authenticity_token"=>"[FILTERED]", "admin"=>{"email"=>"****************", "password"=>"[FILTERED]", "remember_me"=>"0"}, "commit"=>"Log in"}
W, [2024-06-19T14:11:14.097979 #56160]  WARN -- : [5baeac08-4601-4749-ae9e-e913f8789855] Can't verify CSRF token authenticity.
I, [2024-06-19T14:11:14.098817 #56160]  INFO -- : [5baeac08-4601-4749-ae9e-e913f8789855] Completed 422 Unprocessable Entity in 2ms (ActiveRecord: 0.0ms | Allocations: 348)
F, [2024-06-19T14:11:14.101562 #56160] FATAL -- : [5baeac08-4601-4749-ae9e-e913f8789855]
[5baeac08-4601-4749-ae9e-e913f8789855] ActionController::InvalidAuthenticityToken (Can't verify CSRF token authenticity.):
====

Далее  при включенном force_ssl включается так же  проверка  secure cookies.

Если в конфигурации так же добавить
config.ssl_options = {secure_cookies: false}

то ошибка прячется.

Отмечу, что ранее мнение саппорта Locum.ru относительно того, что же такое происходит при включении config.force_ssl = true - несколько, как бы это помягче сформулировать, разнилось относительно сказанного:

support: 15 июня 2024, 13:21
force_ssl  лишь осуществляет принудительный редирект на  HTTPS и добавляет HSTS политику. На  логин данная опция никак не влияет. Эту же информацию Вы можете прочитать в документации rails.

Четко обозначу: описанная в статье проблематика (чуть было не написал "симптоматика") не воспроизводится ни на Heroku, ни на моем рабочем ПК с актуальной версией Fedora. Учитывая апломб вкупе с технической безграмотностью саппорта Locum.ru, столь явно продемонстрированные как нежелание найти причину технической коллизии - однозначно не рекомендую этот хостинг под серьезные проекты на Ruby on Rails (лэндинги и другую мелочевку публиковать можно).

Ошеломленный грандиозностью результатов, полученных в результате предпринятых изысканий ("Can't verify CSRF token authenticity" при включенном force_ssl - ровно то самое, о чем я неоднократно говорил саппорту, тратя свое время на дебаг и логирование проблемы, которую невозможно воспроизвести иначе, нежели на хостинге Locum.ru, и не имея доступа к конфигам хостинга) - я популярно объяснил умельцам, что думаю о подобном стиле работы. Нет, русского мата себе не позволил, но субъективные впечатления передать попытался. За что был немедленно лишен доступа к панели управления хостингом Locum.ru без каких бы то ни было объяснений и предупреждений.

Уточню: мой баланс на счету аккаунта был на тот момент положительным, а на сервере хостинга Locum.ru крутились два моих приложения, являющихся, как-никак, объектами интеллектуальной собственности.

После письма на Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript., содержание которого сводилось, если вкратце, к обещанию обратиться в суд и банальной сентенции "ребята, а вы не оxyели там, часом?" - мне оперативно вернули доступ к моему программному коду и заодно оплату за последний месяц. Чем я и воспользовался, дабы незамедлительно удалить с сервера Locum.ru свои проекты.

Тем не менее... ну, вы понимаете. Ни Hostgator, ни Heroku, никакие иные забугорные хостинги никогда не давали мне повода столкнуться с таким абсурдом, как Locum.ru. Конец истории.

Здесь, наконец, украинские читатели блога получают возможность вволю позлорадствовать. Ось так, хлопці. Така ось сталася нездорова херня.