|
To activate his account the user has to enter a key which is stored in the database in his account-record. How do we find this record? Well, we search the table:
$loginname = $_POST['loginname'];
$keyEntered = $_POST['key'];
$query = "SELECT * FROM user";
$result = mysql_query($query) or die(mysql_error());
while($row = mysql_fetch_array($result)){
if ($keyEntered == $row["activator"]){
$sql="UPDATE user SET activator = '', status='activated' WHERE username = '$loginname'";
mysql_query($sql);
$time=time()+ 365*24*60*60;
setcookie("check", "1",$time);
}
}
if ($keyEntered != $row["activator"])
{
$msg2="Invalid key";
}
So:
- No escaping of the entered POST-parameters.
- First query fetches ALL datasets!
- WHERE-clause in second query takes the loginname given by the user, not the id of the dataset found
Can this be worse?
|
|
|
|
|
Yes, it can.
Garnish the whole thing with some empty catch blocks. Obfuscate these horrors with a generous helping of spaghetti (code). Use only obscure abreviations as names for variables. Avoid comments at all cost. Throw in some lengthy and totally needless string manipulation to avoid having to use any other data type. Let those string manipulations fail (sometimes) because the string was null to begin with, which omits about 10000 code lines by going directly to the empty catch block.
Or how about this: Send some query to get a filled dataset with several tables and many rows. Then clear out all the rows (but prevent them from being deleted in the database). This way you conveniently get a dataset to fill with your own new rows. No hassle with setting up the dataset first.
And I have this and many more great ideas in one big ball of rubbish. And the spaghetti parts are so good that any attempt to replace the most horrible parts one by one is doomed to fail.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
If your code is clean, short, concise and has excellent method/function/variable/class names, then you can "Avoid comments at all cost."
|
|
|
|
|
Ha! You made some good suggestions! Unfortunately the genius about who I'm talking already managed most of your ideas. I will bring more examples, you will see! 
|
|
|
|
|
Clippy: I see that you entered the wrong password. The correct password is "apple"; shall I enter it for you?
|
|
|
|
|
imagiro wrote: $time=time()+ 365*24*60*60;
Does nobody know that there are 86,400 seconds ina day? [I can't prove this but I have thios ingrained in my long-term memory.]
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
Distant memories of childhood wonderment: Eight six four two zero(es). And yes, it has been useful these last 60-odd years.
Cheers,
Peter
ps No idea why you got downvoted. Have my 5 in at least partial compensation.
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Nagy Vilmos wrote: Does nobody know that there are 86,400 seconds ina day? [I can't prove this but I have thios ingrained in my long-term memory.]
Just last week I wrote a formula that included "numdays * 86400" and then I replaced it with "numdays * 24 * 60 * 60" because that adds clarity for the people who don't know how many seconds are in a day. If other people are going to read your code, it's easier to do 24*60*60 than to add a comment explaining why you're multiplying by 86400.
|
|
|
|
|
Indeed.
Your compiler should do that multiplication as part of the optimization stage anyway, so feel free to leave arithmetic on constants like that in your code as long as it improves the situation.
Even if it didn't optimize that out, if you're waiting on the SQL server to retrieve your results like that, the last thing you'll notice is 2 extra integer multiplication operations.
|
|
|
|
|
Wow. So you replaced a "magic number" with a set of "magic numbers" for clarity?
Replace the thing with a constant and you'd be doing far, far better.
|
|
|
|
|
#define SECONDS_IN_A_DAY 86400
is clearer and slightly educational to the reader, so definitely a better solution
You trivialize my approach as using "magic numbers", but in the real world probably 90% of the population can tell what you're doing if you do 24 * 60 * 60 whilst maybe 15% of people know what 86400 is. So, I'd still say 24 * 60 * 60 is clearer than 86400 despite it being 3 "magic numbers" instead of 1. Astonishingly, if you add a fourth magic number, nearly every literate human on the Western calendar understands it with no explanation: "365 * 24 * 60 * 60".
|
|
|
|
|
Charvak Karpe wrote: but in the real world probably 90% of the population can tell what you're doing if you do 24 * 60 * 60
You haven't worked with some of the developers I work with now. No, they couldn't tell you what that code was doing... seriously.
|
|
|
|
|
I didn't, but for some reason I know there are 525,600 minutes in a year. 
|
|
|
|
|
A workable "slide rule" approximation: 1 year = 10^7.5 seconds. [A leap year is even closer!  ]
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
|
All is revealed! From the "Eight Days a Week" school of mathematical chronology. 
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
I kid you not - genuinely found in production code. Has raised a smile or two in our office.
If flag < 1 And flag > 3 Then Exit Function
That's actually not the worst problem with the code, but definitely the funniest.
|
|
|
|
|
Methinks the guy who works for my company has a sibling who works for yours.
Though, if "flag" is a delayed computation with overridden operators, that could actually turn out to be true (e.g., square root of 100 is both positive and negative 10).
|
|
|
|
|
It is still bad though!
------------------------------------
I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
CCC League Table Link
CCC Link[ ^]
|
|
|
|
|
Your post the other day was part of my inspiration for my point about the square root of a number... so you're partly to blame for my silliness! 
|
|
|
|
|
That was one of the reasons I immediately posted it - the coincidence of seeing yours so recently.
I almost wish there was something clever like that going on, but no, flag is declared as an Integer.
As DD pointed out though, even if that was the case its still a horror. I'm coming round to the view that operator overloading maybe a bad idea because of the potential for abuses like this. Although I note that D provides a better implementation, where defining opCmp covers the whole family of <, <= etc. preventing abuses like that (to an extent).
|
|
|
|
|
I unfortunately must disagree.. no amount of language feature or design constraint can save you from a programmer lacking in programming skills. The only solution for THAT problem is good code review and a team willing to point out ways to improve (and enforce them) to the souls who are in this occupation but shouldn't be.
And.. your original post is hilarious and sad at the same time. For the same reasons.
|
|
|
|
|
A simple kind of integration between two application is that one application calls the other application via the command line, passing a few parameters. A customer wanted to call our application from their main application. On the configuration form, he entered the parameters to be passed:
OurProgram.exe /param1=[InternalValue1] /param2=[InternalValue2]
When calling OurProgram from their MainApplication, MainApplication parses the command line parameters and replaces internal values with their present values, i.e. it eventually calls:
OurProgram.exe /param1=John /param2=Doe
It works, but there is a catch: the user cannot work now in MainApplication because it waits for OurProgram to exit.
Our customer called the manufacturer of MainApplication, and they told him to add another parameter dontblock, i.e.
OurProgram.exe /param1=[InternalValue1] /param2=[InternalValue2] /dontblock
When MainApplication finds the dontblock parameter while parsing the command line, it knows that it need not wait for the called application to exit.
It works, but again, there is a catch. It now calls
OurProgram.exe /param1=John /param2=Doe /dontblock
and OurProgram complains that it does not know the parameter dontblock.
Great design!
|
|
|
|
|
Sounds like [Manufacturer] is passing the buck instead of having to deal with it...
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Perhaps a better way would have been to use the start command. Do they not know DOS?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
