|
Was it like this?
Uncheck □ this -> □ if □ you □ are □ not □ a bot □.
|
|
|
|
|
No, just the one checkbox.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Can't find it with Google. Is the most relevant result hidden from me?
|
|
|
|
|
Wow, that's very ... uhm ... secure.
I once came across a site where they showed a series of pictures with checkboxes and you had to check all the vehicles and leave the rest unchecked. Try writing a bot for that.
|
|
|
|
|
Algorithm: Randomly check or uncheck each box. If there's five pictures, then you'll successfully bypass the security 1/32 times.
Bots have infinite patience, and checkbox-based security can usually be brute-forced.
|
|
|
|
|
jesarg wrote: 1/32 times
Are you assuming exactly one vehicle? I assumed that any, all, or none would meet the criteria.
Whoops, no, I see it now, sorry.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
There were about 30 pictures perhaps. If you only allowed a few tries before it locked up, it would be pretty secure, I suppose. (I'm not an expert) But nothing is 100% secure of course.
|
|
|
|
|
I thought this forum consisted of only experts! (then I ask myself why would I be here then!)
|
|
|
|
|
If you display a lot of pictures at once, then the system becomes just as annoying to users as a captcha.
Also, you'd have to maintain a large and constantly-changing database of pictures to keep the bot from memorizing which pictures are the vehicles.
In any case, defeating the bots is a much bigger task than people realize. If bot writers are willing to create advanced algorithms capable of deciphering a captcha, then they are willing to go to great lengths to defeat other security features, too.
|
|
|
|
|
I've seen that with "Kittens" and "Puppies" as well - very damn annoying!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
For something I'm working on, I want to test a given XmlElement with a provided XPath predicate to determine whether or not it's the droid node I'm looking for.
public static bool
IsMatch
(
this System.Xml.XmlElement Element
,
string Predicate
)
{
return ( Element.SelectSingleNode ( "self::node()[" + Predicate + "]" ) != null ) ;
}
I wasted an hour trying to get .[predicate] to work.
System.Xml.XmlDocument doc = new System.Xml.XmlDocument() ;
doc.LoadXml ( "<Foo Bar='Baz' />" ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "." ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "self::node()[@Bar='Baz']" ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "self::*[@Bar='Baz']" ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( ".[@Bar='Baz']" ).OuterXml ) ;
<Foo Bar="Baz" />
<Foo Bar="Baz" />
<Foo Bar="Baz" />
System.Xml.XPath.XPathException: '.[@Bar='Baz']' has an invalid token.
The book I have says . is equivalent to self::node() , but that's not true,
. returns a node, whereas self::node() returns a node-set, and you can only apply a predicate to a node-set.
Of course, if you know of a way to test a node that uses neither SelectSingleNode nor SelectNodes, I'd be glad to see it.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: Of course, if you know of a way to test a node that uses neither SelectSingleNode nor SelectNodes, I'd be glad to see it.
How about this?
public static bool IsMatch(this System.Xml.XmlElement element, string predicate)
{
return element.CreateNavigator().Matches("*[" + predicate + "]");
}
If you're going to be re-using the same predicate for a lot of elements, you might want to pre-compile it[^]:
public static bool IsMatch(this System.Xml.XmlElement element, XPathExpression compiledPredicate)
{
return element.CreateNavigator().Matches(compiledPredicate);
}
...
var compiledPredicate = XPathExpression.Compile("*[" + predicate + "]");
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks, I'll try that too and maybe do some performance comparisons. Performance really isn't an issue with my current usage -- about forty elements being checked with a predicate provided on the command-line.
Your second implementation might make for the basis of an enumerator.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Found an interesting feature in Microsoft Dynamics Ax 2012 R2:
static void Job40(Args _args)
{
smmBusRelTable bus;
int i;
select count(RecId) from bus where
bus.BusRelAccount == bus.TopLevelAccount
;
info(strFmt("From count: %1", bus.RecId));
i = 0;
while select bus where
bus.BusRelAccount == bus.TopLevelAccount
{
i++;
}
info(strFmt("bus.BusRelAccount == bus.TopLevelAccount: %1", i));
i = 0;
while select bus where
bus.TopLevelAccount == bus.BusRelAccount
{
i++;
}
info(strFmt("bus.TopLevelAccount == bus.BusRelAccount: %1", i));
}
Running the job results in this output:
From count: 31597
bus.BusRelAccount == bus.TopLevelAccount: 1
bus.TopLevelAccount == bus.BusRelAccount: 31597
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
A badly designed operator override? At least fun to see that (bus.BusRelAccount == bus.TopLevelAccount) != (bus.TopLevelAccount == bus.BusRelAccount)
|
|
|
|
|
I wish it was that easy. But X++ does not have overrides, the Dynamics Ax VM creates SQL statements from this code.
By tracing statements in the SQL Server I may be able to see the different statements created, but the bottom line is, that this should be a very very simple comparison, and having a failure here, gives me the creeps.
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
Ah, I see. Reminds me of an old "obfuscted" Access database, where
SELECT * FROM A, B where A.ID=B.A_ID
was different from
SELECT * FROM A JOIN B ON A.ID=B.A_ID
The trick was that in one case padding with spaces was relevant, in the other case not.
|
|
|
|
|
Ha!
I found the problem. DAX uses a caching mechanism to avoid too many roundtrips to the SQL Server.
If you're using the primary key in a query, then DAX will search an in-memory cache to retrieve a single record.
Apparently, DAX gets confused when I use the primary key field busRelAccount on the left hand side of the comparison. Using bus.disableCache(true) fixes this problem.
I hope they get rid of this bug soon, I really don't like to think of all the places I could have trusted this to just work.
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
Because there is no other way to compare OrderNumber to 0
Private Function IsNew(ByVal OrderNumber As Long) As Boolean
Return IIf(OrderNumber = 0, True, False)
End Function
It's not horrible, but it's pretty representative for the code as a whole.
A lot of redundancy, a lot of global variables, no null values (but still NullReferenceExceptions...), Forms with 1000+ lines of code, etc.
VB is not the problem, it's the programmers that code it.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Where do you see the problem behind that code that justifies it to be posted in the Weird and Wonderful?
Well, that IsNew function should better be a function of the Order class and not need a parameter (because OrderNumber could be expected to be a Property).
But otherwise? Does VB.Net have the ternary operator like C# (return OrderNumber = 0 ? true : false;)? I don't know.
Or did you want to tell us that it's better to do the comparison of OrderNumber to 0 whenever that IsNew function is used? Oh no! That would deserve to be posted here! IsNew clearly tells you the intention of the code, while If(OrderNumber=0) does not.
|
|
|
|
|
It is a function on the Order class, but it still takes a parameter (it just gets mOrderNumber given to it every time).
VB does not have a ternary operator.
I'm saying the function could look like this:
Return OrderNumber = 0
There is no need for an IIF anywhere in the code. As I said, it's not truly horrible, but it's an 'interesting' way to return if OrderNumber = 0
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Ah, thanks. That explains it. It really deserves this place.
|
|
|
|
|
Don't worry, we all have our off-days
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
I guess it was an unhandled ConfusedByVBException ...
|
|
|
|
|
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|