9

Наш производственный сервер в течение нескольких месяцев производит ложные ошибки токена аутентификации. Ошибки создаются почти во всех формах, отправляющих запросы (PUT | POST | DELETE). Иногда возникает ошибка, иногда они этого не делают. Похоже, что нет рифмы или причины, почему они происходят. Сама ошибка не возникает часто, но это беспокоит нас. Ниже приведен пример типичной формы, которая вызывает эту ошибку.Отладка случайных ошибок аутентификации подлинности подлинности

<form class="button_to" method="post" action="/lesson_progress_trackers/333"> 
    <input type="hidden" name="_method" value="patch"> 
    <input class="finish-lesson-button" type="submit" value="Done!"> 
    <input type="hidden" name="authenticity_token" value="Qd3FsJZY2UXR9vahuFmaY5rrqA+J5xzGpl4cGI2Vwerx8PZPQtDMugz6oqoe3iviC+/U5zTYPdeX3apwbap09E=="> 
    <input type="hidden" name="completed" value="true"> 
</form> 

Вот что я обнаружил до сих пор.

  1. Мы используем Turbolinks 2.5.3 (мы не обновляем это более года).
  2. В каждом случае недопустимой ошибки токена пользователь передал токен аутентификации на сервер, он просто оказался недействительным.
  3. В настоящее время мы используем protect_from_forgery with: :exception в нашем контроллере приложений.
  4. Ошибки начали появляться, когда несколько месяцев назад мы выпустили кучу нового кода. Этот новый код охватывает сотни файлов, но до сих пор я ничего не нашел в коде, который бы имел отношение к этой проблеме.
  5. Ошибка может возникать на любом типе браузера и устройства.
  6. Нет корреляции между увеличенным трафиком и недействительными токенами auth.
  7. Пользователи могут приезжать из любой страны.
  8. Это не боты, испытывающие эти проблемы. У нас даже был опыт коллеги по этой ошибке, хотя они не могут вспомнить, что они сделали для ее создания.
  9. Пользователи следуют типичным, если не ожидаемым поведением. Они используют приложение, как предполагалось. Я просмотрел их клики и записал историю поведения, чтобы завершить это.

В конечном счете, я хочу выяснить, как это решить. Мой первый шаг - успешно воспроизвести ошибку, но я даже не могу этого сделать. Мой вопрос заключается в следующем: что я могу сделать, чтобы помочь мне понять, что вызывает это? У меня заканчиваются варианты. Благодаря!

+0

Да, я сделал это. Это происходит для реальных пользователей. Это не боты. Образцы, которые я обнаружил, являются типичным поведением пользователя. Нет ничего ненормального в том, что они делают. Я готов сказать, что это ожидаемое поведение. Вот почему это так страшно. – jason328

+0

Можете ли вы исключить, что что-то истекает? Cookies - это всего лишь одно, это может быть какое-то связанное с временем сравнение, неправильное время на сервере, поле базы данных, которое ожидает определенное время или что-то в этом роде. – Smar

+0

Я так не думаю? Вы можете немного уточнить свой вопрос. – jason328

ответ

1

Не знаю, если это слишком поздно, чтобы быть полезным, но у меня была та же проблема. Я был в состоянии воспроизвести:

  1. Убедитесь, что вы вышли из приложения
  2. открыть вкладку браузера, чтобы знак в странице
  3. Пусть это сидеть достаточно долго, чтобы истечь сессию/CSRF токен (может быть несколько часов)
  4. Открыть другую вкладку на странице входа и войти в систему
  5. вернитесь на старую вкладку и попробуйте войти в систему снова. Исключено исключение InvalidAuthenticityToken.

Я думаю, что это произошло для меня, потому что две вкладки разделили один сеанс, сеанс, который был создан при открытии новой вкладки. Однако на старой вкладке все еще был токен csrf из старого сеанса в форме входа. Когда новый файл cookie сеанса и старый токен csrf были отправлены вместе, они не совпадали и, следовательно, ошибка была выбрана.

Я не уверен, как это исправить, кроме обработки ошибки более изящно, чтобы пользователь не увидел смущающую страницу ошибки.

BTW, я использую устройство, но я не думаю, что он специфичен для Devise.