Last post Dec 08, 2005 04:36 PM by cathal
Dec 06, 2005 04:01 PM|jmillar|LINK
Dec 07, 2005 05:41 AM|leupold|LINK
Dec 07, 2005 08:39 AM|jmillar|LINK
Dec 07, 2005 09:01 AM|cathal|LINK
Jason, at present you can't disable it (as the documents state we haven't added support for passwordAttemptThreshold or passwordAttemptWindow). Setting these values will not affect dotnetnuke behaviour, and as their both integers setting them to a value
larger than 2,147,483,647 (or whatever internal maxiumum Microsoft has coded) will cause an error.
Dec 07, 2005 09:18 AM|jmillar|LINK
Dec 07, 2005 01:54 PM|ech01|LINK
Dec 07, 2005 02:05 PM|KorbanD|LINK
Dec 07, 2005 05:30 PM|FuzzyGuru|LINK
It is rather unfortunate that the Core has not been updated to use some of the base features that Microsoft provided in their backported membership provider. It should be rather simple process to "turn on" some of these features.
Of course, it would be really nice if you could adjust these on a per portal basis, not just for the whole installation.
Dec 08, 2005 04:36 PM|cathal|LINK
Thanks Cathal -- the value I tried was 100, which I assume isn't over the bounds of an integer [:)]...not much point in pursing it, though, if it's not going to alter the behaviour. I think I saw a blog post by you mentioning the defaults for Threshold and
Window were 5 and 10 respectively...just so I know what to expect, is that accurate?
Just did a bit of checking, and we only use the default threshold value (which is 5) . The actual lockout is handled by a dotnetnuke function, which uses the Auto-unlock accounts after (minutes) value that can be specified in host->host settings. It's set
to 10 by default, but you can change it i.e. if you change it to 1, it would allow for 5 failed passwords per minute before lockout.