Estoy esperando algunos comentarios sobre el método que va a utilizar para la prevención de registros duplicados en una ASP.NET MVC 4 aplicación, y los efectos no he pesar de la experiencia de los usuarios.

El formulario web tiene seis campos de entrada y un botón de guardar (así como un botón «cancelar»), los Usuarios pueden tomar hasta 10 minutos a rellenar el formulario.

Una vez que los campos se presentan a través de un post de la página es redirigido en el éxito /fracaso a una página diferente, después de que los datos se registran en una tabla de base de datos utilizando un nuevo Guid como la clave principal.

Para detener los usuarios pulsando el botón guardar muchas veces, pero que permite al navegador para volver a publicar la solicitud en una conexión cerrada tengo la intención de proporcionar el Guid para los nuevos registros de clave principal como un oculto campo de entrada cuando el formulario se procesa.

Si el repost que pasa, o el usuario presiona guardar varias veces, la base de datos del servidor rechazará el segundo post de el registro, ya que de un duplicado de la llave, que puedo comprobar y hacer frente con el lado del servidor.

Pero, ¿crear grandes problemas para mí?

  • ¿Cuál es el problema?
  • El único momento que existe un problema con poner el Identificador de Clave Principal en un campo oculto es que los usuarios pueden ir en ese campo y cambiar la clave principal y la actualización de todos los registros en la databse. ahora, ya que son Guid será casi imposible adivinar Guid que ya han ben utilizado y ir en una actualización de los anteriores del usuario formas , si estás usando un número entero, a continuación, me gustaría por lo que es una mala idea
  • Han utilizado Bootstrap? Porque automáticamente disabvles el botón y si no usar jquery o algún gestor de u ocultar el botón de hasta u recibir respuesta de la solicitud post’
  • En la actualidad, sin que ello nuevos registros se han repetido hasta siete veces cuando los clientes de las redes están ocupados y los usuarios esperan una respuesta más rápida.
  • Empecé a deshabilitar el botón guardar, pero de vez en cuando a la izquierda del usuario, sin ningún camino a seguir. El formulario fue atrapado, el servidor no había conseguido el puesto, y que tiene que volver a escribir todo. El problema es que el navegador no sabe si el servidor no obtener el POST o que el navegador no obtener la respuesta.
  • Posibles duplicados de ¿Cómo puedo evitar que varios de envío de formulario en .NET MVC sin usar Javascript?

InformationsquelleAutor Old fart | 2015-01-13

5 Comentarios

  1. 3

    Si usted hace uso de un oculto anti-falsificación token en su forma (como debería), usted puede almacenar en caché la anti-falsificación token en primer lugar presentar y eliminar el símbolo de la caché si es necesario, o caducar con una entrada de la caché después de establecer la cantidad de tiempo.

    Entonces usted será capaz de revisar con cada petición en contra de la caché si la forma específica ha sido presentado y la rechazará si es así.

    Usted no necesita generar su propio GUID como esto ya se hace en el momento de generar la anti-falsificación de token.

    ACTUALIZACIÓN

    A la hora de diseñar su solución, por favor, tenga en cuenta que cada solicitud será procesada de forma asincrónica en su propio hilo, o tal vez incluso en completamente diferentes servidores /app instancias.

    Como tal, es completamente posible que varias solicitudes (hilos) puede ser procesada, incluso antes de la primera entrada de caché. Para evitar esto, implementar la caché como una cola. Cada envío(solicitud post), escribir el nombre de la máquina /id y id al hilo de caché, junto con el anti-falsificación token… retraso de un par de milisegundos, y, a continuación, compruebe si la entrada más antigua en la memoria caché/de la cola para que el anti-falsificación token corresponde.

    Además, todas las instancias de ejecución debe ser capaz de acceder a la caché (caché compartida).

  2. 3

    Puede evitar la doble clic desde el lado del cliente usando algunos de jQuery, si quieres.

    En el HTML, tiene su botón de enviar algo parecido a esto:

    <a id="submit-button"> Submit Form </a> <span id="working-message"></span>

    De JavaScript (jQuery):

    $('#submit-button').click(function() {
      $(this).hide();
      $('#working-message').html('Working on that...');
      $.post('/someurl', formData, function(data) {
        //success 
        //redirect to all done page
      }).fail(function(xhr) {
        $('#submit-button').show();
        $('#working-message').html('Submit failed, try again?');
      });
    }); //end on click

    Esto ocultará el botón incluso antes de que se intenta presentar, por lo que el usuario puede hacer clic dos veces. Esto también muestra el progreso, y en caso de error, les permite volver a presentar. Es posible que desee pensar acerca de la adición de un tiempo de espera para que mi código.

    Otra alternativa es el uso de jquery para agarrar el formulario $('#form-id').submit(), pero usted no será capaz de rastrear el progreso tan fácilmente como la llamada ajax que he hecho.

    EDICIÓN:
    Aun así, recomendaría buscar formas para evitar la doble presentación de un server-side stand punto, por razones de seguridad.

    • Muy interesante, gracias, yo no había mirado a ajax porque estoy utilizando el ASP.NET MVC 4 patrón y tenía la esperanza de mantener el MVC 4, cada vez más, viendo que es mejor alejarse de MVC4. Todavía con la esperanza de una respuesta MVC4
    • Hey no hay problema! 🙂 Yo uso MVC4 y MVC5 extensamente en mi día a día, pero yo casi siempre uso este patrón dentro de mi aplicación MVC para el envío de formularios. Esto permite mucha más flexibilidad, y siempre puedo usar otros MVC opciones para validar los datos «server side». Echa un vistazo a JsonResult: usted puede crear acciones en su aplicación MVC que se atiende a este tipo de jQuery / ajax llamadas.
  3. 0

    Simplemente puede tratar con él en el lado del cliente.

    Crear una superposición div, una clase css con pantalla de ninguno y una de las grandes de la z-index y un script jquery que muestra que el div cuando el usuario presiona el botón de enviar.

    • De vez en cuando a la izquierda del usuario, sin ningún camino a seguir. El formulario fue atrapado, el servidor no había conseguido el puesto, y que tiene que volver a escribir todo. El problema es que el navegador no sabe si el servidor no obtener el POST o que el navegador no obtener la respuesta.
    • No hay necesidad de que haya un gran índice z si la pantalla está configurada para ninguno.
    • Sí, pero eventualmente va a mostrar el div y cuando lo haga, debe estar en la cima
    • claro, pero estamos hablando de un escenario en el que tienes un montón de capas – que el OP no ha indicado es el caso, ni debe ser la norma.
  4. 0

    Como yo lo entiendo, usted está planeando para mantener la clave principal en una entrada ocultos cuando la visualización de la página inicial. Obviamente, esto no es una buena idea. Para comenzar con, si usted está utilizando el Guid de la implementación en c#, es de cadena y cadena de tener como clave primaria no es una buena idea (Véase la respuesta a esta pregunta ASÍ).

    Puede solucionar este problema de dos maneras. En primer lugar, Desactivar el botón con el primer clic. Segundo, construir las validaciones en el código detrás, sin depender de la clave principal.

    • se publicó un enlace a una pregunta que estaba sobre el rendimiento de Guid vs int como primary key clustered index – que tiene muy poco que ver con esta pregunta , excepto el hecho de que ambos mencionar Guid
    • Dejando de lado el Guid PK problema de rendimiento que soy consciente y tomar a bordo. El tema de la seguridad me preocupa demasiado, pero he sido incapaz de definir un problema real con él, excepto para la persona que finge las entradas ¿tienes los enlaces para ayudar con esto?
    • Excepto por el problema de rendimiento y posibilidad de Guid de la manipulación, que no hay problemas con este método. De hecho, usted ni siquiera necesita para mantener el Guid como el PK. Puede insertar el Guid junto con el registro y comprobar para ver si un registro con este Guid ya existe justo antes de la inserción.
  5. 0

    A veces, tratar con él sólo en el lado del cliente no es suficiente. Tratar a la generación de un código hash de la forma y guardar en caché (establece una fecha de caducidad o algo así).

    el algoritmo es algo así como:

    1 – Usuario que hizo el post

    2 – Generar el hash del post

    3 – Comprobar el hash en memoria caché

    4 – Post que ya están en la memoria caché? Lanzar la excepción

    5 – Post no está en la caché? Guardar el nuevo hash en memoria caché y guardar el post en la base de datos de

    Un ejemplo:

                //verify duplicate post
                var hash = Util.Security.GetMD5Hash(String.Format("{0}{1}", topicID, text));
                if (CachedData.VerifyDoublePost(hash, Context.Cache))
                    throw new Util.Exceptions.ValidadeException("Alert! Double post detected.");

    La función de caché podría ser algo así:

        public static bool VerifyDoublePost(string Hash, System.Web.Caching.Cache cache)
        {
            string key = "Post_" + Hash;
    
            if (cache[key] == null)
            {
                cache.Insert(key, true, null, DateTime.Now.AddDays(1), TimeSpan.Zero);
                return false;
            }
            else
            {
                return true;
            }
        }

Dejar respuesta

Please enter your comment!
Please enter your name here