html - attribute - El formulario se envía aleatoriamente como GET en lugar de POST

title html attribute

Question

Esto es un poco loco.

Aquí hay un formulario en nuestro proveedor de 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>

Este formulario forma parte de una página (en /affiliate/form/login ) alojada en un iframe. El iframe se sirve a través de HTTPS, la página de host a través de HTTP. Puede ver esto en acción en /users/login usando una ventana de navegación de modo incógnito / navegación privada / pornografía.

Entonces, aquí está el problema, periódicamente (pero no de manera sistemática ) un usuario OBTENDRÁ en lugar de POST a esta URL. Esta es una ocurrencia absurdamente baja, que afecta a menos de 50 usuarios totales hasta la fecha.

Estoy tentado a solo dev/null estos errores (no hay método de acción, etc.), pero ...

Parecen usuarios reales: una amplia variedad de IPs, agentes de usuarios variados y válidos, y tiempos creíbles. Frustrantemente, los mismos usuarios a veces publican exitosamente la misma forma un poco más tarde.

¿Alguna idea de lo que podría estar causando esto?

Ideas que he tenido y descartado:

• Acelerador HTTPS o solicitudes de intercambio de equilibradores de carga
  • revisaron los registros entrantes, coinciden con lo que está llegando a la aplicación
• Error de análisis de solicitud ASP / .NET
  • Comparados entre los valores de solicitud entrantes y registrados, coinciden
• Buggy browser
  • Apariciones registradas en múltiples versiones de Chrome, FireFox 4, Safari y Mobile Safari
• Bots, o extensiones de navegador de mala calidad.
  • Amplia gama de navegador, IP y sistema operativo.

Mi mejor conjetura actual es que el ?affId=# en la acción está disparando algo (aunque no constantemente, otra vez). Esto es básicamente la depuración de vudú, así que me encantaría una explicación más autorizada.

Actualización: Probé mi corrección de vudú ( <input type="hidden" name="affId" value="#" /> y así sucesivamente), e implementé. No tengo un repro, así que lo estoy dejando cocer.

Vemos una pareja al día en promedio, así que si esto se hornea para más de 2 personas sin problema, lo publicaré como la respuesta.

Segunda actualización: No, sigue ocurriendo. Sin embargo, mucho menos frecuentemente. Estoy recopilando más datos para ver si hay algo en común en términos de navegadores o sistemas operativos.

La teoría operativa sobre la razón por la cual eliminar ?affId=# de la acción ha reducido la ocurrencia es que los proxies con errores frente a los clientes obtienen de manera optimista "cosas que parecen seguras para OBTENER". Esta es una suposición salvaje, así que trátela con un grano de sal.

Tercera actualización: Más evidencia de proxies falsos. Consultar registros para las direcciones IP afectadas (durante un período de tiempo mucho más largo), y muchos de ellos tienen tasas de solicitud mucho más altas que la mayoría de las personas no afectadas. No está 100% cortado y seco, y estoy seguro de que un poco de refresco frustrado aumenta los conteos, pero ... sigue siendo un indicador razonable (la diferencia es de 5 veces el número de solicitudes en el mismo período para los IP afectados) ).

En este punto, me estoy moviendo para detectar el error que se ha producido y proporcionar mejores mensajes de error y orientación. Más bien no entusiasta de obtener una respuesta autorizada, especialmente porque parece que esa respuesta se encuentra en el ámbito del "código que no controlo".

Answer 1

Algunas extensiones de navegador con bloqueo de anuncios, como AdBlock Plus Popup addon ''sonda'', páginas complementarias para determinar su URL real antes de decidir si bloquearlas. Específicamente, el complemento emergente mencionado anteriormente hace esto con las consultas HEAD de forma predeterminada, pero puede configurarse para hacer consultas GET.

Answer 2

Asegúrese de que el código fuente esté bien formateado ejecutándolo a través de un validador.

Answer 3

Tuvo un problema similar con los usuarios de Chrome y la causa fue que si alguien envía un formulario con shift + enter en google Chrome, el navegador abrirá una nueva pestaña y realizará una solicitud GET sin parámetros. Dado que las personas a menudo tienen caracteres en mayúscula / especiales como último carácter de una contraseña, presionan Intro antes de liberar el turno y luego se emite la solicitud GET.

Veo que mencionó Chrome primero al enumerar los navegadores, por lo que si el problema ocurre en Chrome con mayor frecuencia, probablemente se deba a esta razón.

Si bien este no es el único problema que tiene, probablemente contribuya.