Подтвердить что ты не робот

Форма произвольно представляется как GET вместо POST

Это сумасшедший.

Здесь форма поставщика OpenID:

  <form method="post" action="/affiliate/form/login/submit?affId=7" autocomplete="off">
    <table class="position-table">
      <tr>
        <td class="input-td">
          <input class="framed-text-field" type="text" name="email" id="email" value="" maxlength="100" />
          <span class="form-help">[email protected]</span>
        </td>
        <td class="input-td">
          <input class="framed-text-field" type="password" name="password" id="password" />
          <span class="form-help">Password</span>
        </td>
        <td></td>
        <td class="input-td">
          <input type="submit" class="affiliate-button" value="Sign In" />
        </td>
      </tr>
    </table>
    <input type="hidden" id="fkey" name="fkey" value="REDACTED" />
  </form>

Эта форма является частью страницы (в /affiliate/form/login), размещенной в iframe. IFrame обслуживается через HTTPS, хост-страница через HTTP. Вы можете увидеть это в действии на /users/login с помощью/окно браузера инкогнито/частный просмотра порно-режиме.

Итак, вот проблема, периодически (но не последовательно) пользователь будет GET вместо POST на этот URL. Это абсурдно низкое явление, затрагивающее менее 50 пользователей на сегодняшний день.

У меня возникает соблазн просто dev/null этих ошибок (без действия и т.д.), но...

Они выглядят как настоящие пользователи: широкое распространение IP-адресов, разнообразные и действительные пользовательские агенты и правдоподобные тайминги. Разочарочно, одни и те же пользователи иногда успешно отправили POST одну и ту же форму чуть позже.

Любые идеи, что может быть причиной этого?

Идеи, которые у меня были и отброшены:

  • HTTPS-ускоритель или запрос балансировки нагрузки
    • проверены входящие журналы, они соответствуют тому, что нужно получить в приложении
  • Ошибка анализа запроса ASP/.NET
    • По сравнению с входящими в журнал значениями запроса они соответствуют
  • Багги-браузер
    • Записанные записи в нескольких версиях Chrome, FireFox 4, Safari и Mobile Safari
  • Боты, или мутные расширения браузера
    • Широкий браузер, IP и ОС.

Мое самое лучшее предположение заключается в том, что ?affId=# в действии отключает что-то (хотя и не последовательно, снова). Это в основном отладка вуду, поэтому я хотел бы получить более авторитетное объяснение.


Обновление: Пробовал исправление voodoo (<input type="hidden" name="affId" value="#" /> и т.д.) и развернуто. У меня нет репродажа, поэтому я просто даю ему испечь.

Мы видим пару в день в среднем, поэтому, если это испечет за 2+ без проблем, я отправлю его в качестве ответа.


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

Операционная теория о том, почему удаление ?affId=# из действия уменьшило возникновение, - это багги-прокси перед клиентами, оптимистично получающими "вещи, которые выглядят безопасно GET". Это дикая догадка, поэтому относитесь к нему с солью.


Третье обновление: больше доказательств для фиктивных прокси. Запрос журналов для затронутых IP-адресов (в течение более длительного периода времени), и многие из них имеют гораздо более высокие ставки запросов, чем большинство незатронутых. Его не на 100% вырезать и сушить, и я уверен, что некоторые разочарованные обновления увеличивают количество очков, но... его все еще разумный индикатор (разница составляет 5 или более запросов за тот же период для затронутых IP-адресов).

В этот момент я перейду к обнаружению ошибки и предоставил лучшие сообщения об ошибках и рекомендации. Довольно неохотно о том, чтобы на самом деле получить авторитетный ответ, тем более, что этот ответ, похоже, лежит в сфере "кода, который я не контролирую".

4b9b3361

Ответ 1

Некоторые рекламные блокирующие расширения браузера, такие как AdBlock Plus Popup addon сопутствующие страницы, чтобы определить их реальный URL, прежде чем принимать решение о блокировке их. В частности, упомянутый выше всплывающий аддон делает это с запросами HEAD по умолчанию, но может быть настроен на выполнение запросов GET.

Ответ 2

У вас была аналогичная проблема с пользователями Chrome, и причина заключалась в том, что кто-то отправляет форму с помощью shift + enter в Google Chrome, браузер откроет новую вкладку и сделает запрос GET без параметров. Поскольку у людей часто есть символ верхнего регистра/специальный символ в качестве последнего символа пароля, они нажимают клавишу ввода, прежде чем отпускать сдвиг, и затем выдается запрос GET.

Я вижу, что вы упомянули Chrome сначала при перечислении браузеров, поэтому, если проблема чаще возникает в Chrome, возможно, по этой причине.

Хотя это, вероятно, не единственная проблема, которая у вас есть, это, вероятно, способствует.

Ответ 3

Убедитесь, что исходный HTML хорошо отформатирован, запустив его через валидатор.