aip Work Item Rss Feed

Created Feature: Support Attribute: autocomplete="off"

davedev — Wed, 31 Dec 2008 18:49:56 GMT

Add a boolean AutoCompleteDisabled property (default=true) that controls the inclusion of an autocomplete="off" attribute on the input control in the default template (when false, simply exclude the autocomplete attribute). When present, this attribute will prevent browsers from saving old CAPTCHA answers for auto-completion, which should never be reusable, in theory.

Netscape 6.2 (Mozilla 0.9.4) or later. IE 5 or later:
https://developer.mozilla.org/En/How_to_Turn_Off_Form_Autocompletion

Opera:
http://list.opera.com/pipermail/opera-users/2004-December/024627.html

See also:
http://msdn.microsoft.com/en-us/library/ms533032(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms533486(VS.85).aspx

Created Feature: Add "New" Button in Web Control's Default Template

davedev — Mon, 11 Aug 2008 10:54:42 GMT

The AIP web control should provide a way for people to request a new image immediately, if for example the current challenge is too difficult to solve.

A button with a "refresh" or "recycle" image seems common among CAPTCHA control systems. The button can probably just post back to the server in order to have a new image generated, but it must not cause validation to occur.

In the default control template the button should be hidden unless explicilty enable by setting a boolean property on the web control to true; e.g., ShowRecycleButton="True".

Original discussion:
http://www.codeplex.com/aip/Thread/View.aspx?ThreadId=33276

Commented Issue: Inconsistent behaviour of validation controls

davedev — Tue, 05 Aug 2008 17:05:24 GMT

The AutoInputProtectionControl has the properties InvalidErrorMessage, InvalidErrorText, RequiredErrorMessage and RequiredErrorText that are mapped as:
InvalidErrorMessage -> Validator.ErrorMessage
InvalidErrorText -> Validator.Text
RequiredErrorMessage -> RequiredValidator.ErrorMessage
RequiredErrorText -> RequiredValidator.Text

The control also has a default value if some of those properties are not set.

However, in the Validators, this apply (extracted from the documentation):

"If you set the ErrorMessage property without setting the Text property, the value of the ErrorMessage property is also displayed in the validation control."

So, I expected to set only the InvalidErrorMessage and the RequiredErrorMessage in order to have the inline and validation summary errors with that text but the control uses the default ("*") if I don't specify the InvalidErrorText and RequiredErrorText properties.
Comments: ** Comment from web user: davedev **

Thanks, the behavior will be updated for the next release.

Created Issue: Inconsistent behaviour of validation controls

mabadia — Tue, 05 Aug 2008 15:41:49 GMT

Commented Issue: Parse configuration values using InvariantCulture

mabadia — Tue, 05 Aug 2008 15:34:59 GMT

I don't see the benefit of allowing culture specific parsing in the configuration. It causes only problems.

I don't like the current implementation of the Parse* in the ProviderHelper class because it doesn't use the InvariantCulture when parsing floats for example. If I develop on a machine with WinXP spanish I need to put opacity=",35". However if I deploy to a machine with W2k3 server english this fails because it expects opacity=".35".

I think culture specific strings/numbers/dates are useful in UI or string messages but not in configuration settings.
Comments: ** Comment from web user: mabadia **

dave, i think the invariantCulture="true|false" will be enough for my needs. thanks

Commented Issue: Parse configuration values using InvariantCulture

davedev — Tue, 05 Aug 2008 14:43:54 GMT

Maybe a reasonable solution is to add support for a new attribute on the autoInputProtection element:

invariantCulture="true|false"

It would be false by default.

Commented Issue: Parse configuration values using InvariantCulture

davedev — Tue, 05 Aug 2008 14:40:00 GMT

Thanks for adding this issue.

I'll consider using the invariant culture for the next release, although I'm not sure that I agree at the moment.

The problem with using the system's culture, in your case, is that the production server uses a different culture. A work-around is to use a different web.config for deployment, which is typical of most web apps anyway since most, at the very least, require that debugging be disabled on a production server - by modifying the web.config file. (In VS you can use a Web Deployment Project to help.)

The benefit of using the current culture is mainly for convenience (if deployment isn't a real concern). For example, a text provider can accept a string of characters that are permitted by random selection and then rendered to the UI. Also, numbers and dates can be formatted according to a user's native culture, requiring less knowledge about invariant (English) formatting.

Created Issue: Parse configuration values using InvariantCulture

mabadia — Tue, 05 Aug 2008 09:04:37 GMT

Created Feature: Support an Alternative Provider for Accessible CAPTCHA implementations

davedev — Sat, 19 Jul 2008 19:24:27 GMT

Since CAPTCHA image challenges are not highly accessible to users with disabilities, support an "alternative" provider mechanism that provides accessibility-friendly implementations that can be plugged in much like how image, filter and text providers can be plugged in now.

The provider implementation should be designed to handle a wide range of implementations, such as Q&A and audio-based CAPTCHA.

The AIP web control should be extended to support an "alternative" hyperlink, hidden by default, with a public boolean property that can be set to make it visible. When visible, the default template should show the hyperlink either above or below the image or text box (perhaps configurable via another property on the AIP web control). Developers of custom AIP web control templates should be able to add a control with an appropriate type and ID value for the hyperlink in much the same way as the image, text box and validators can be added now.

Original discussion:
http://www.codeplex.com/aip/Thread/View.aspx?ThreadId=31838

Commented Issue: Breaks img w3c sctandard without alternate text

davedev — Sat, 19 Jul 2008 18:56:19 GMT

Or I don't see where is it
Comments: ** Comment from web user: davedev **

Ok, fair enough :) We can continue the discussion in your thread:

http://www.codeplex.com/aip/Thread/View.aspx?ThreadId=31838

Commented Issue: Breaks img w3c sctandard without alternate text

serializer — Sat, 19 Jul 2008 15:30:22 GMT

Or I don't see where is it
Comments: ** Comment from web user: serializer **

I've posted an item in Discussions relating to accessibility.

Since I've spent a lot of time making all parts of my website accessible, it seems a shame then to prevent such users from registering...

The alt text really should say "This is a CAPTCHA image. If you are unable to view this image, please click the next link for an alternate challenge..."

Commented Issue: Breaks img w3c sctandard without alternate text

davedev — Tue, 15 Jul 2008 02:41:25 GMT

Or I don't see where is it
Comments: ** Comment from web user: davedev **

What would you expect the alternate text to say? "CAPTCHA image"? Since this solution isn't accessibility-friendly, it kind of defeats the purpose of the standard, don't you think? ;)

Anyway, you can add alternate text by creating a custom template. The documentation has some info on templates.

Created Issue: Breaks img w3c sctandard without alternate text

mgigirey — Wed, 09 Jul 2008 10:17:36 GMT

Or I don't see where is it

CLOSED TASK: Production Testing

davedev — Wed, 02 Apr 2008 01:32:41 GMT

Test AIP on a production web server that receives automated spam on a consistent basis.
Comments: Tested on my personal blog for a couple of weeks. My blog receives steady streams of automated spam. With the latest version of AIP I have not received any spam comments on my blog; without the control, I was receiving dozens per day.

CLOSED TASK: Refactor

davedev — Wed, 02 Apr 2008 01:30:15 GMT

Refactor various aspects of AIP. Keep track of breaking changes.
Comments: Done.

CLOSED ISSUE: Remove Requirement for "dsweb" Section Group

davedev — Wed, 02 Apr 2008 01:30:01 GMT

The <dsweb> section group in a web.config file does not add any value. It should not be required.
Comments: This has been implemented. Existing web.config files will no longer be valid.

CLOSED FEATURE: Standardize the Web Control

davedev — Wed, 02 Apr 2008 01:29:04 GMT

1. Add public style properties for each of the composited controls.
2. Recreate the AIP web control to use the typical templated-control paradigm; e.g., use a container and a default template.
3. Get rid of the AIP placeholder controls since they aren't really necessary.

Instead of placeholder controls, the following controls must be found in a custom template or a runtime error should occur:

ID: Type
Image: System.Web.UI.WebControls.Image
Validator: System.Web.UI.WebControls.CustomValidator

The following controls should be optional, although if they are specified then the AIP web control should apply their styles and attributes like normal:

ID: Type
Title: System.Web.UI.ITextControl
Instruction: System.Web.UI.ITextControl
Label: System.Web.UI.ITextControl
ValidationText: System.Web.UI.ITextControl
RequiredValidator: System.Web.UI.IValidator
Comments: Just "Text" is required for the text box ID instead of "ValidationText", although it is optional anyway. Although, setting the appropriate ID will allow you to set the style using the TextBoxStyle property on the AIP web control and the text will automatically be cleared on every post back.

CLOSED FEATURE: VS 2008 Toolbox Installation

davedev — Wed, 02 Apr 2008 01:26:01 GMT

The installer offers to place the AIP web controls into the Visual Studio 2005 toolbox only. The next release should support VS 2005 and VS 2008, offering each one independently if they are detected on the system.
Comments: Done.

CLOSED ISSUE: Bypass Vulnerability

davedev — Wed, 02 Apr 2008 01:25:38 GMT

Somebody from websecurity.com.ua has contacted me regarding a vulnerability of AIP. I was able to confirm that reusing an older web form to bypass AIP, even if the CAPTCHA image is no longer valid, is in fact a vulnerability of AIP.

See the original article here:
http://websecurity.com.ua/1568/

See my blog for more information about the AIP 2.0.0 implementation:
http://davesexton.com/blog/blogs/blog/archive/2007/12/12/aip-1-0-0-bypassed.aspx
Comments: This has been fixed according to the information provided in my blog post. Some of the particular details mentioned no longer apply, however.

CLOSED TASK: Visual Studio 2008

davedev — Wed, 02 Apr 2008 01:24:31 GMT

Test for compatibility with Visual Studio 2008.
Comments: The latest release is compatible. The source code has been upgraded to C# 3.0 and Visual Studio 2008, although the assembly still targets the .NET Framework 2.0 so that 3.5 is not a requirement on web servers.