BotDetect CAPTCHA ASP.NET P+F

Sí, puede usar el BotDetect CAPTCHA con ASP.NET 2.0.

BLa vesión trial y la full del producto vienen con instalaciones separadas ASP.NET 1.1 y ASP.NET 2.0, conteniendo las versiones respectivas del componente e incluyen proyectos ejemplo acordes a su versión de su framework .NET.

Sí, puede usar BotDetect CAPTCHA control con versiones de .NET framework 3.0 y 3.5. Solo use el paquete de instalación de BotDetect CAPTCHA ASP.NET 2.0.

La versión ASP.NET 2.0 de BotDetect es compatible con versiones más nuevas, debido a que ambas versiones .NET están corriendo en el mismo núcleo del runtime .NET 2.0 - .NET 3.0 y .NET 3.5 implementandose como actualizaciones de librería por para el núcleo del framework .NET 2.0.

Sí, BotDetect CAPTCHA control desde el paquete ASP.NET 2.0 funcionanrá sin problemas cuando lo agregue a proyectos de Visual Studio 2008.

Los proyectos de ejemplo incuídos en la instalación funcionarán luego de correr el Asistente de Conversión, que se iniciará automáticamente cuando lo abra en Visual Studio 2008.

Sí, el estado de la sesión ASP.NET es necesario para BotDetect.

Por favor tenga en cuenta que no debe ser el InProc estado de sesión predefinido – puede usar cualquier proveedor de Microsoft o uno personalizado (base de tados, servidor de estado, sistema de archivos, etc.). Tenga en cuenta de que el estado de la sesión de memoria InProc no debe ser el predeterminado, usted puede usar cualquiera de Microsoft o uno personalizado desde cualquier proveedor (base de datos, servidor de estados, archivos, etc.).

BotDetect no ncesita un modo specífico de persistencia (funcionará tan pronto como pueda guardar datos en algún lugar), pero debido a que ASP.NET provee una manera de personalizar el modo exacto de persistencia y conectarlo al objeto predeterminado Session (como se explica en http://msdn2.microsoft.com/en-us/library/aa479034.aspx, todas las llamadas hechas en el código BotDetect son hechas usando el objeto Session

Sí. Tenga en cuenta que BotDetect CAPTCHA necesita persistencia de Estado de Sesión, entonces tendrá que habilitar Session State para su aplicación web. Un escenario Granja web/ Jardín Web, significa que:

• Configrura ASP.NET para usar modos de Stado de Sesión persistentes de SQL Server or .NET State Server, y matiene el Estado de Sesión para todo su Granja Web en un solo servidor.
• Continúa usando Estado de Sesión InProc en cada servidor individual, lo que significa que tendrá que asegurarse que los clientes retornen a servidor su información de Estado de Sesión Existente data en todas las solicitures Http luego de la primera. Esto se conoce como agregar conexiones pegadizas. Por favir verifique sus ajustes de balanceo de carga load-balancer.

Para más información acerca de estos temas, consulte el siguiente enlace:

• http://www.hanselman.com/blog/Permalink.aspx?title=LoadBalancingAndASPNET
• http://www.informit.com/articles/article.aspx?p=31842&seqnum=3

No necesita volver hacer nada cuando compra la versión final de Control BotDetect ASP.NET CAPTCHA.

Puede desarrollar con la versión trial, y luego de comprar solo reemplazar el binario Lanap.BotDetect.dll en su servidor. De esta manera no necesita redesarrollar o recompilar.

Esto es explicado con más detalle en la página Información de restricciones de la version de pruebas de BotDetect CAPTCH.

Sí, desde la version 2.0, BotDetect corre bajo ASP.NET 2.0 en nivel medio de confianza.

En otras palabras, el binario Lanap.BotDetect.dll ha sido marcado con:

[assembly: System.Security.AllowPartiallyTrustedCallers]

Sen necesita un HttpHandler para generar imágenes CAPTCHA. No guardamos esas imágenes en el disco duro o las reutilizamos de ninguna manera, pero las generamos al-vuelo por razones de seguridad. Un ASP.NET HttpHandler permite generar imágenes CAPTCHA que solo el usuario en curso pueda ver, y que permiten solo un intento de validación por código CAPTCHA.

Sí, BotDetect ASP.NET CAPTCHA funciona con IIS 7.0. Si está corriendo ASP.NET en modo integrado, necesita agregar la siguiente declaración a su archivo de proyecto web.config:

<system.webServer>
  <validation validateIntegratedModeConfiguration="false" />
  <handlers>
    <remove name="LanapCaptchaHandler"/>
    <add name="LanapCaptchaHandler" preCondition="integratedMode" 
      verb="*" path="LanapCaptcha.aspx" 
      type="Lanap.BotDetect.CaptchaHandler, Lanap.BotDetect" />
  </handlers>
</system.webServer>

Lo que sucede es que para ejecutar el código descrito necesita privilegios de administrador. Desafortunadamente los accesos directos para archivos .bat no tienen la opción "Ejecutar como administrador" en las opciones del menú contextual del menú inicio. Entonces, lo que puede hacer es:

1. Elija "Browse Samples Folder" desde el mismo menú en donde se encuentra "1st install the samples.bat"
2. Haga clic secundario en el archivo InstallSamples.bat y elija "Ejecutar como administrador"

• Si usted está utilizando BotDetect CAPTCHA en un proyecto Web ASP.NET o una aplicacción web ASP.NET MVC (en comparación con un sitio Web de ASP.NET), usted debe recompilar su proyecto con la nueva versión de Lanap.BotDetect.dll integrada, y desplegar la estructura actualizada.
• Si usted está utilizando la utilidad de registración de BotDetect CAPTCHA para seguir los errores de BotDetect o validación CAPTCHA de intentos, usted también tendrá que poner al día Lanap.BotDetect.Troubleshooting.dll e incorporar a la nueva versión.
• Si usted se refiere al ensamblado de Lanap.BotDetect.dll con el número de versión compleato y el PublicKeyToken (en su archivo de web.config o en la directica de ejemplo @Register), usted tendrá que poner al día estos valores para emparejar el nuevo lanzamiento.

LanapCaptcha.aspx es un HttpHandler declarado en el binario Lanap.BotDetect.dll, y no exixte en su disco duro (como un archivo). Este es un agradable artículo explicando la lógica HttpHandler: http://www.devx.com/dotnet/Article/6962/1954?pf=true.

En breves: no tiene que buscar el archivo LanapCaptcha.aspx. Sencillamnete agregue la referencia de componente Lanap.BotDetect.dll a su proyecto, y el control de Captcha al formuario web. Entonces, abra el archivo web.config y agregue la declaración HttpHandler a la sección <system.web>:

<system.web>
  <httpHandlers>
    <add verb="*" path="LanapCaptcha.aspx" 
      type="Lanap.BotDetect.CaptchaHandler, 
        Lanap.BotDetect"/>
  </httpHandlers>
</system.web>
    

Guarde todos los os cambios, compile y corra el proyecto y verá una imgen CAPTCHA renderizada en su formulario web. Puiede también mirar Cómo usar BotDetect ASP.NET CAPTCHA en Visual Studio 2005, donde todos los pasos son explicados con mayor detalle.

Necesita deshabilidar verificaciones de autentificación para las solicitures de BotDetect CAPTCHA. agreando este código dentro de la sección <configuration> de su archivo web.config solucionará el problema:

<location path="LanapCaptcha.aspx">
  <system.web>
    <authorization>
      <allow users="*"/>
    </authorization>
  </system.web>
</location>

Si tiene instalado BotDetect CAPTCHA para ASP.NET y BotDetect CAPTCHA para ASP, sea cuidadoso de usar únicamente la versión .NET en proyectos ASP.NET.

Cuando agrega una referencia a la versión ASP en un Proyecto .NET, Visual Studio autmáticamente genera la Capa de Inteoperabilidad COM (Interop.LANAPBOTDETECTLib.dll), pero la interfaz resultante de componente es aún diferente y no fácilmnete utilizable desde proyectos ASP.NET.

La versión .NET de BotDetect CAPTCHA puede ser encotrada en

C:\Archivos de programa\Lanapsoft\BotDetect\ASP.NET 2.0\v2.0\
  Assembly\Lanap.BotDetect.dll

La versión COM de BotDetect CAPTCHA está ubicada en

C:\Archivos de programa\Lanapsoft\BotDetect\ASP\v2.0\Component\
  LanapBotDetect.dll

Cuando remueve la referencia a Interop.LANAPBOTDETECTLib.dll y agrega una Lanap.BotDetect.dll, aparecerá este error.

ACTUALZIACIóN: Este problema ha sido resuelto por completo en BotDetect para ASP.NET v2.0.10 (lanzado el 2008-04-06), entonces solo tiene que actualizarse a la versión más nueva.

Las intrucciones que contiuan solo se aplican a BotDetect versiones 2.0.6 - 2.0.9, son aún funcionales, pero consideradas antiguas.

LA solución a este problema requiere BotDetect for ASP.NET v2.0.7 (lanzado el 2007-07-18) o más nuevo. Si tine una versión más vieja, por favor contactenos para una actualización.

ademá de cargar el último .dll a su servidor(es), también necesita hacer un pequeño cambio a la declaración de elemneto <sessionState> en su su archivo web.config de aplicación. Por ejemplo, isi está usando una declaración cómo:

<sessionState mode="InProc" cookieless="AutoDetect" 
  timeout="20" />

Por favor cámbiela a:

<sessionState mode="InProc" cookieless="AutoDetect" 
  timeout="20" sessionIDManagerType="
    Lanap.BotDetect.Persistence.CustomSessionIDManager, 
    Lanap.BotDetect" />

Luego de agregar el valor personalizado sessionIDManagerType no debería experimentar ningún problema.

Explicación

Este problema es causado por Windows Media Player 11 (utilizado en Vista), que aparentemente hace 2 solicitudes consecutivas para un click en el audífono (todos los otros reproductores - incluyendo Windows Media Player 9.0 y 10.0 - sólo hacen ina única solicitud). La primera solicitud que de hecho funciona apropiadamente (el código es leído esde estado de Session etc.), ppero la segunda solicitud viene sin la Session cookie de ASP.NET, causnado una Session completamente nueva (y un nuevo código) sea creado.

Si isa la versión actualozada del .dll, y hace cambios en un web.config escrito antes, la Session ID (que es usualmente persistente en la Session cookie de ASP.NET, o en el fragmente de Url con sesiones ausentes de cookies) es pasado como parámetro de cadena de consulta de la solicitud de sonido. El Session ID Manager personalizado es entonces usado para reconocer usuarios que retornan y generar el archivo de sonido desde la información correcta de Session.

Una solución aternativa es siempre usar Sessions siempre ausentes de cookies. Si prefiere eso, por favor note que todos las Urls en su aplicación serán cambiadas para incluir la Session ID, mientras que usando la primera solución solo cambiará el audio la Url solicitada de CAPTCHA.

Para resolver este problema necesita hacer un pequeñ o cambio a la declaración de elemento <sessionState> en su archivo de aplicación web.config . Por ejemplo, si está usnado una declaración como:

<sessionState mode="InProc" cookieless="AutoDetect" 
  timeout="20" />

Por favor cambiela a:

<sessionState mode="InProc" cookieless="AutoDetect" 
  timeout="20" sessionIDManagerType="
    Lanap.BotDetect.Persistence.CustomSessionIDManager, 
    Lanap.BotDetect" />

Luego de agregar el valor personalizado de sessionIDManagerType no debería tener ningún de nuevo este problema .

Explicación

Nuestra investigación de este problema muestra que Chrome reenvía el la solicitud de sonido CAPTCHA a Windows Media Player, que por alguna razion hace la solicitud son la cookie de Session de ASP.NET, creando una nueva Session y nuevo código.

Si hace el cambio en el archivo web.config, la Session ID (que es usualmente persostente en la cookie de ASP.NET Session, o en el fragmento de Url sin cookies) es pasado como parámetro de cadea de consulta del sonido. La Session ID Manager personalizada es entonces usad para reconocer usuarios que vuelven y generar el archivo de sonido desde la información de Session correcta.

Una solución alternativa es siempre usar Sessions ausentes de cookies. Si prefiere esto, por favor note que todas las Urls en so aplicación serán cambiadas para incluir la Session ID, mientras la primera solución solo cambia la solicitud al audio CAPTCHA.

Este problema puede ser resuelto excluyendo la imagen BotDetect CAPTCHA y los los senderos de sound en la configuración de DotNetNuke. El único paso adicional necesario para usuarios de DotNetNuke es agregar:

<RewriterRule>
  <LookFor>.*LanapCaptcha.aspx(.*)</LookFor>
  <SendTo>~/LanapCaptcha.aspx$1</SendTo>
</RewriterRule>
    

a SiteUrls.config en la base del direcotrio web y BotDetect CAPTCHA funcionará apropiadamente.

Este problema es específico de servidores de carga balanceada usandoInProc ASP.NET Session State y conexiones pegadizas.

El problema con usuarios de AOL es que están conectados contínuamente a través de proxies, y no necesariamente tienen la mimsa IP en las consultas posteriores. Dependiendo en sus ajustes de su balanceo de carga, esto puede causar que Conexiones pegadizas dejen de funcionar para ellos. Esto causa que las solicitudes de imágenes CAPTCHA sean procesadas en el servidor incorrecto, sin las variables Session variables que necesitan.

Puede encontrar más explicaciones en:

• In-process Session State + Más de UN Servidor Web en http://www.hanselman.com/blog/LoadBalancingAndASPNET.aspx
• Problemas con ASP Session State -> Limitaciones de Granjas de servidores en http://msdn2.microsoft.com/en-us/library/ms972429.aspx
• ¿Comportamiento normal de proxy AOL o ataque DOS? en http://groups.google.com/group/microsoft.public.inetserver.iis.security/
  browse_thread/thread/1842b9172aab60e3/17446b9c304253ce?lnk=st&q=AOL+
  session+state+ASP.Net&rnum=3&hl=hr#17446b9c304253ce

• In-process Session State + More than One Web Server at http://www.hanselman.com/blog/LoadBalancingAndASPNET.aspx
• Problems with ASP Session State -> Server farm limitations at http://msdn2.microsoft.com/en-us/library/ms972429.aspx
• Normal AOL proxy behavior or DOS attack? at http://groups.google.com/group/microsoft.public.inetserver.iis.security/
  browse_thread/thread/1842b9172aab60e3/17446b9c304253ce?lnk=st&q=AOL+
  session+state+ASP.Net&rnum=3&hl=hr#17446b9c304253ce

Entonces la solución podría ser también:

• Usar un único servidor para persistencia Session State en todos servidores de balanceo de carga (usando los modos SQL or StateServer ASP.NET Session State).
• O, puede ral vez configurar su implementación de balanceo de carga para implementar exitosamente conexiones pegadizas incluso para usuarios de AOL. Por ejemplo, el hardware balanceador de carga puede agregar su cookie par así mismos, etc. Por favor verifique la documentación de su balanceador de carga para más detalles.

El captcha no funciona en este escenario porque el estado ASP.NET Session is no está siendo apropiadamente persistente para el usuaerio final. El problema aparece en IE por lo siguiente:

• En todas las solicitudes luego de la primera, el usuario es retornado estado apropiado de Session state usando el la cookie ASP.Net Session
• Su cookie de Session state está configurada para el Dominio #1 (con el form que contiene el BotDetect CAPTCHA)
• La página principal (que contiene<iframe>) está ubicada en el Dominio #2
• Cookies ubicadas para diferentes dominios de la página principal son conocidos como cookies de terceros; son conocidas como causas de problemas de seguridad, y son bloqueadas por defecto en IE
• Cuando abra su página en IE7, puede confirmar esta la cusa del problema cambiando sus ajustes de IE para permitir cookies de terceros( Herramientas> Opciones de Internet> Privacidad > Avanzadas). Cuando haga este cambio, el CAPTCHA debería funcionar apropiadamente

Solución

Debería modificar definitivamente su código para que no use cookies de dominio cruzado, debido a que muchos usuarios las tienen bloqueadas por defecto y como buena práctica.

La solución más simple es configurar su aplicación (el formulario que contiene el CAPTCHA) para que siempre use Sessions ASP.NET ausentes de cookies - perdurando la actual SessionID en un fragmente de Url, en vez de una cookie.

Puede hace esto cambiando la declaración de elemento <sessionState> en el archivo web.config (el mismo en el que registró BotDetect HttpHandler). Por ejemplo, si está usando una declaración como:

<sessionState mode="InProc" cookieless="AutoDetect" 
  timeout="20" />

Por favor cambiela a:

<sessionState mode="InProc" cookieless="true" 
  timeout="20" />

Observe que la Url cambiará dinámicamente en el formulario de BotDetect CAPTCHA para agregar el fragmento de SessionID (algo como /(S(vi1maxipelkbz2ahryodzirf))/), pero no debe afectar la Url de su página principal(salvo que ccambie el archivo web.config de esa página también).

En la única situación que obtendrá errores de este tipo es cuando el cliente hace una clase particular de solicitud de imagen CAPTCHA o sonido inválida. Esto sucede usualmente con bots tratando de acceder a la página.

En particular, si los registros de su servidor muestran que este error sucede con la cadena User Agent similar a Mozilla/3.01 (compatible;), o la cadena de consulta es algo cómo esto get=image&amp;c=default_ctl00_contentplaceholdermain_captcha1 &amp;t=3172526 2 - con el &amp; en vez de &, puede asegurarse que algún tipo de bot. Todos los navegadores modernos resuelven las entidades XHMTL apropiadamente, entonces los humanos no deberían tener ninún problema con esto.

Hemos agregado soluciones para esto en BotDetect para ASP.NET v2.0.8 (entidades &amp; en solicitudes) y v2.0.10 (solicitures conteniendo constructors tipo-&amp;amp;amp;), entonces esto invalida las solicitudes qCAPTCHA que no resulten en ninguna excepción y se registran. Si tiene una versión más antigua, por favor contatenos por una actualización.

Las solicitures a BotDetect CAPTCHA deberían ser definitivamente bloqueados en el archivo robots.txt.

Hay un número de Urls ligeramente diferentes reportadas debido a que Googlebot rastrea página sin cookies, y las Urls de ASP.NET ausenete de cookies cambian en cada visita(éstas son scritas para contener la Session ID).

Aquí tiene como cloquear estas solicitures en el archivorobots.txt:

User-Agent: Googlebot
Disallow: /*/LanapCaptcha.aspx
Disallow: /*/WebResource.axd
# other googlebot restrictions go below
/forbidden.html
# ...

User-Agent: *
# other restrictions go below
/forbidden.html
# ...

Debido a que las Ulrs de estas solicitudes cambian dinámicamente, pueden ser bloqueadas para Googlebot por un extensión específica de robots.txt implementada por Google (el caracter asterisco). Aunque, otros rastreadores podrían no entender el caracter asterisco, entonces esta declaración necesita estar en la parte específica de Googlebot del archivo robots.txt.

También, observe que generalmente archivos rohibidos (como se muestran en el earchivo ejemplo forbidden.html ) necesitan estar declarados dos veces: tanto en la sección específica de Googlebot y na las generalesdel archivo robots.txt. Desafortunadamente, así es como el estándar robots.txt funciona - Googlebot solo leerá la sección User-Agent: Googlebot, e ignorará las declaraciones User-Agent: *.

Puede hace el botón Recargar la la derecha del ícono del audífono agregando las siguientes declaraciones al los estilos CSS de la página CAPTCHA-protected:

#LBD_CaptchaDiv{
  width: 310px !important;
}

#LBD_CaptchaDiv #LBD_CaptchaIcons {
  width: 55px !important;
  height: 25px;
}

#LBD_CaptchaDiv #LBD_CaptchaIcons img {
  padding-right: 4px !important;
}

Si la imagen CAPTCHA tiene un alto diferente de 250 pixels, cambien la primera declaración de acuerdo según la siguiente fórmula:

<#LBD_CaptchaDiv width> = <CAPTCHA image width> + 60 px.

Esto mostrará los íconos en un diseño horizontal, como se muestra en el screenshot de abajo.

Si quiere evitar postbakces de página completa, puede hecar un vistazo al Demo Ajax BotDetect CAPTCHA Ajax Demo incluido con la instalación, que usa ASP.NET Ajax UpdatePanel para publicar solo la parte de la página con el CAPTCHA.

Validación CAPTCHA puramente del lado del cliente

Validación CAPTCHA pura del lado del cliente (sin ningua comunicación con el server) no está soportada por BotDetect, debido que es trivial saltarla, y no provee ninguna protección seria de los bots. Por ejemplo:

• Desea publicar comentarios que únicamente hayan resulto el CAPTCHA.
• Si la validación está puramente del lado del cliente, significa que el código JavaScript debe enviar al comentario de usuario al servidor cuando el código CAPTCHA sea recuelto correctamente.
• Entonces el spammer solo necesita resolver el CAPTCHA una vez, y pretar atención al resultado: e.g. enviando un parámetro específico vía POST, o redireccionado a una página específica.
• Luego él podrá simular el mismo contexto en su bot y saltar el CAPTCHA- sencillamente falseando el parámetro POST, o accediendo a la redirección directamente.
• Puede hacer una copia de la parte del cliente solo validando la misma entrada de usuario el en servidor una vez que la página es publicada y antes de guardar el comentario de usuario
• Pero debido que está conservando la solición correcta en el lado del clietne, los bots podrían sencillamente acceder a ese código y luego resolver el CAPTCHA correctamente.

Los detalles exactos dependen de su caso específico y del escenario de integración CAPTCHA. Pero escencialmente, todo código del lado del cliente es inseguro y puede ser flseado o modificado con propósitos malintencionados- Como consecuencia, los códigos CAPTCHA deben permanecer el en servidor, y toda la validación CAPTCHA debe ser realizada por el servidor.

Validación CAPTCHA del lado del cliente - la solución

Puede evitar postbacks de página completa usando ASP.NET Ajax u otra librería Ajax para hacer validación CAPTCHA asincrónica al servidor, y procesar el resultado en el cliente:

• Cuando la validación Ajax CAPTCHA falle, puede mostrar al usuario una nueva imagen CAPTCHA sin afectar el resto de la página, promoviendo la navegabiliad de la página.
• Debería mostrar siempre el código CAPTCHA en tales casos, ebido a que permitiendo varios intentos para el mismo CAPTCHA hace más sencillo el aprendizaje de OCR.
• Cuando la validación CAPTCHA sea exitosa, debería entonces enviar la página al servidor y validar la entrada de usuario CAPTCHA nuevamente.
• Solo luego de una validación CAPTCHA exitosa del lado del servidor debería ejecutar la operación "protegida" (ejemplo, guardar el comentario de usuario).

La consulta AspxAutoDetectCookieSupport=1 es agregada automáticamente por ASP.NET durante la fase de detección de cookie. Debido al atributo <sessionState> cookieless en el archivo web.config es es ajustado a "AutoDetect", la rutina de ASP.NET trata de detectar si el usuario soporta cookies, y el parámetro de consulta es agregado durante el proceso. Si las Cookies son soportadas, el Session ID es mantenido en una cookie, si noes asó el Session ID es enviado a la Url de todas las consultas futuras del usuario.

La única manera de remover la conslta es ajustar el el atributo cookieless a "true" o "false" en su archivo web.config. Pero en ese caso, todas las Urls serán dinámicamente cambiadas para incluir el identificador ASP.NET Session (cookieless="true"), o validación CAPTCHA siempre fallará para usuarios que tiene cookies deshabilidas en sus navegadores (cookieless="false").

Debido a esto es construido por ASP.NET, tendrá que decidor que valor de cookieless es apropiado para su aplicación. Puede leer más acerca de ausencia de cookies en http://msdn.microsoft.com/en-us/library/aa479314.aspx.

El comportamiento de nuestro demo en línea está relacionado con el timeout de ASP.NET Session - debido que los códigos CAPTCHA son guardados en el estado ASP.NET Session, y nuestro demo en línea usa el timeout de Session state de 20 minutos, este comportameinto es más o menos para un diseño.

Si su página requiere que los códigos CAPTCHA duren por largos peridos de tiempo, puede:

• Incrementar el atributo de Session timeout de <sessionState> en su archivo de proyecto web.config. Sin embargo, esto incrementará el consumo de memoria de IIS por que la información Session data se mantendrá por cada cliente conectado. Y si algunos usuarios permanecen en su página más del timeout que ajustó, ellos aún tendrán este problema.
• Una mejor solución será mantener el timeout de Session bajo (20 minutes), y tener un script en el cliente "latidos de corazón" que prolongue la Session para usuarios que está en la págian más tiempo. Por ejemplo, debido que el timeeout por defecto es 20 minutes, el código Javascript podría hacer a solicitud asincrónica (Ajax) a su aplicación cada 15 minutos, manteniento la Session viva si los usuarios abren la página y permanencen inactivos por largos perorodos de tiempo.

Sio el CAPTCHA auditivo en su proyecto es diferente del renderizado por el código en la imagen incluso cuando no superó el timeout de Session, debería investivar en otros ajustes. Por ejemplo, si está usando InProc ASP.NET Session state, la información puede aún estar perdida, aún que use el script para mantener a los usuarios activos si el procesador de trabajos de IIS se recicla. O, si tiene más de una instancia del roceso de trabajo en el mismo servidor (un jardín web), diferentes procesadores de trabajos tendrán estados Session separados.

En estos casos deberia cambiar su proyecto ya sea a modo StateServer o SQLServer ASP.NET Session, que no son dependientes de procesador de trabajos de IIS.

Aquí tiene un ejemplo de como podría lograrse validar BotDetect CAPTCHA dentro de una entrada de usuario CreateUserWizard.

Forma en código .aspx

Asumamos que tiene la siguiente declaración CreateUserWizard en su archivo .aspx:

<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" 
  OnNextButtonClick="CreateUserWizard1_NextButtonClick">

y modifica el

<WizardSteps>
  <asp:CreateUserWizardStep runat="server">
    <ContentTemplate>

para incluir el siguiente Captcha:

<BotDetect:Captcha ID="Captcha1" runat="server" />
<asp:TextBox ID="CodeTextBox" runat="server"></asp:TextBox>
<asp:Label ID="CodeIncorrectLabel" runat="server" 
  Text="Incorrect code!" Visible="false"></asp:Label>

Forma código subyacente

Puede agregar validación Captcha en su archivo de código subyacente con el siguiente códigoen el manejadorNextButtonClick:

[C#]

protected void CreateUserWizard1_NextButtonClick(object sender, 
  WizardNavigationEventArgs e)
{
    if (e.CurrentStepIndex == 0)
    {
        Captcha Captcha1 = (Captcha) CreateUserWizard1.
          CreateUserStep.ContentTemplateContainer.
          FindControl("Captcha1");
					
        TextBox CodeTextBox = (TextBox) CreateUserWizard1.
          CreateUserStep.ContentTemplateContainer.
          FindControl("CodeTextBox");
				
        Label CodeIncorrectLabel = (Label) CreateUserWizard1.
          CreateUserStep.ContentTemplateContainer.
          FindControl("CodeIncorrectLabel");

        string userInput = CodeTextBox.Text;
        if (!Captcha1.Validate(userInput))
        {
            CodeIncorrectLabel.Visible = true;
            e.Cancel = true;
        }
        else
        {
            CodeIncorrectLabel.Visible = false;
            e.Cancel = false;
        }
    }
}


[VB.Net]

Protected Sub CreateUserWizard1_NextButtonClick(ByVal sender 
  As Object, ByVal e As WizardNavigationEventArgs)

    If e.CurrentStepIndex = 0 Then

        Dim Captcha1 As Lanap.BotDetect.Captcha = _ 
          CType(CreateUserWizard1.CreateUserStep. _
          ContentTemplateContainer.FindControl("Captcha1"), _
          Lanap.BotDetect.Captcha)
					
        Dim CodeTextBox As TextBox = _ 
          CType(CreateUserWizard1.CreateUserStep. _ 
          ContentTemplateContainer.FindControl("CodeTextBox"), _
          TextBox)
				
        Dim CodeIncorrectLabel As Label = _ 
          CType(CreateUserWizard1.CreateUserStep.
          ContentTemplateContainer.FindControl( _ 
          "CodeIncorrectLabel"), Label)

        Dim userInput As String = CodeTextBox.Text
        If (Not Captcha1.Validate(userInput)) Then
            CodeIncorrectLabel.Visible = True
            e.Cancel = True
        Else
            CodeIncorrectLabel.Visible = False
            e.Cancel = False
        End If

    End If

End Sub

Si los usuarios ingresan un código CAPTCHA correcto pero, por ejemplo, falla la validacion de usuario, no deberían tener que resolver ningún otro CAPTCHA. El proósito del CAPTCHA es asegurarse que el usuario es humano, cuando resuelvan satisfactoriamente la primera vez pasarán el test.

Si tiene que retornarlos al formulario poeque algún campo es incorrecto, lo mejor es no mostrarles el CAPTCHA, debido a que el propósito ha sido cumplido. La manera más simple de recordar que el usuario ha resuelto el CAPTCHA satisfactoriamente es guardar el resultado de lado del servidor, por ejemplo:

bool isHuman = SampleCaptcha.Validate(userInput);
Session["IsHuman"] = isHuman;
	
if (Page.IsValid && isHuman)
{
  // the protected code, e.g. account registration or comment post 
}
    

Entonces el valor es verificado antes de mostrar el CAPTCHA al usuario, y elCAPTCHA es únicamente mostrado si no ha sido resuelto:

protected void Page_PreRender(object sender, EventArgs e)
{
  bool isHuman = false;
  if (null != Session["IsHuman"])
  {
    try 
    {
      isHuman = (bool) Session["IsHuman"];
    }
    catch { // ignore errors
    }
  }
	
  
  // don't show the CAPTCHA if already solved
  if (isHuman) 
  {
    SampleCaptcha.Visible = false;
    CodeTextBox.Visible = false;
  }
}

Por razones de seguridad, no es posible conseguir la misma imagen BotDetect CAPTCHA en dos cargas de página, no usar el mismo código para más de una imagen CAPTCHA.