Post #39,878
5/24/02 10:43:21 PM
|
Programming at the coalface with that attitude.
Aiming to write flexible, re-usable code is something that will easily earn you the respect of fellow programmers. The agony comes when you don't have time to do it like that and it has to Just Work and Soon. :-( At least I have opportunities to fix that kind of situation properly. And there is a unique buzz in replacing several dozen similar code fragments scattered in numerous files with one line that does the same thing only faster and better. :-)
And then there's the Hey This Language Has This Neat Feature And If I Use It I Can Make It Spin Cartwheels! er... well, at least do some semi-complex data mangling in a reasonable amount of time, anyway. And I mean features like PHP's variable variables. Or even just 6-dimensional arrays...
Wade.
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #39,884
5/25/02 12:08:43 AM
|
Variable variables are bad
Perl has that as well, and calls them symbolic references. For the vast majority of what people try to use them for, a hash isa better idea. For a full explanation read the three part series starting [link|http://perl.plover.com/varvarname.html|here].
For the remainder, well most of the time that people think they are in the remainder, they are wrong.
And for the record, one of the best features of Perl is strict.pm, which among other things allows you to catch symbolic references and mark them as errors. Because most of the time they are!
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #39,888
5/25/02 7:52:09 AM
|
They are open to incredible abuse, yes.
But IMO they can solve a certain class of problem created by the way PHP handles HTML form variables. And even that will go away if you want to reconfigure PHP (and re-write lots of code :-). I certainly don't use them like that the writer of that article posted indicated people seem to want to use them for!
Goto's are usually considered bad, too, but occasionally, they are The Right Thing. I would say the same thing about Symbolic References.
Wade.
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #39,900
5/25/02 11:49:41 AM
5/25/02 11:56:45 AM
|
I see that as a self-inflicted problem
But IMO they can solve a certain class of problem created by the way PHP handles HTML form variables.
So PHP handles HTML form variables in a stupid way. That causes problems, and you kind of get around those problems with symbolic references. I say "kind of" because you have working code, but it is generally trivially [link|http://www.linuxworld.com/site-stories/2001/0927.php.html|exploitable]. So PHP's stupid handling of HTML form variables on the one hand drives you to the unsafe practice of symbolic references, and on the other opens up a ton of security holes.
Lovely.
As for goto, well yes. There are times that it is appropriate. Generally far fewer times than people think, but there are times. For my thoughts on that, try [link|http://www.perlmonks.org/index.pl?node_id=125963|this discussion] (the root of that thread lead into several interesting directions). As you can see, I don't just blindly reject the use of goto. But if I see a goto in Perl, the odds are pretty good that I will suggest that the programmer seriously rethink what they are doing. (C is a different story. It lacks several control structures which makes using goto to emulate them make some sense.)
Cheers,
Ben
UPDATE: I should point out that I also use symbolic references. Like goto, only after thought and only with what I consider damned good justification.
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
Edited by ben_tilly
May 25, 2002, 11:56:45 AM EDT
|
Post #40,003
5/26/02 10:35:49 PM
|
I am not unaware of the risks.
So PHP handles HTML form variables in a stupid way. That causes problems, and you kind of get around those problems with symbolic references. I say "kind of" because you have working code, but it is generally trivially [link|http://www.linuxworld.com/site-stories/2001/0927.php.html|exploitable]. So PHP's stupid handling of HTML form variables on the one hand drives you to the unsafe practice of symbolic references, and on the other opens up a ton of security holes.
Lovely. Your confidence is re-assuring. [wry smile] I really would like to move away from this, but there are a number of reasons that that can't be done right now, one of them to do with the fact there is a lot of existing code. For the moment, I'm settling for this solution, along with some sanity checks on input values*. FWIW, the pages are an intranet application, not an internet page on the general WWW. As for goto, well yes. There are times that it is appropriate. Generally far fewer times than people think, but there are times. For my thoughts on that, try [link|http://www.perlmonks.org/index.pl?node_id=125963|this discussion] (the root of that thread lead into several interesting directions). As you can see, I don't just blindly reject the use of goto. But if I see a goto in Perl, the odds are pretty good that I will suggest that the programmer seriously rethink what they are doing. (C is a different story. It lacks several control structures which makes using goto to emulate them make some sense.) I agree 100%. If I need a goto in C it is always my last recourse and is used to implement a missing language feature. Other languages I use do not have goto and I do not miss it - they tend to have the language feature I use goto for in C. :-) UPDATE: I should point out that I also use symbolic references. Like goto, only after thought and only with what I consider damned good justification. Ditto likewise. I appreciate the points-of-view, but we appear to differ in what we each think is "good justification". Wade. * More detail: AFAIK all of my code playing with symbolic references of form data is from code that dynamically generates the field names, anyway, and always from a list of numbers from a database. This list of numbers is currently passed in a hidden field (no, not ideal, I agree) and used by the form-processing code to re-generate the field names for processing the input data. "All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #40,006
5/26/02 11:18:21 PM
|
The main reason for our difference...
is that I don't have a code base to work from that makes avoiding symbolic references difficult. It is much easier to be holier than thou about problems you don't have. :-)
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #40,013
5/27/02 12:29:49 AM
|
*grin*
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #40,036
5/27/02 10:02:30 AM
|
ROFL!
Alex
"Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill (1874-1965)
|
Post #40,165
5/28/02 10:57:09 AM
|
What do you think about this situation
I think the namespace collision is handled properly, but I'd like a fresh set of eyes on it.
In class.Session.php (pseudocode):
$result = "SELECT * FROM session_values WHERE session_id = '$sid'";
foreach( $result as $key => $val ){
$this->$key = $val;
}
In other files:
$session = new Session($sid);
if( $session->username ){
echo "username = ".$session->username;
} else {
echo "username is not set";
}
There is (currently) only one named variable in the session class that can't be set by new code, as it would cause a collision. But since the method for setting new session variables is in the Session class, I can prevent that variable from ever being added to the session_values table. (It just concatenates username_first and username_last to get username_display.)
I understand the issue in the article you pointed to, but I think I've avoided the problem. Did I miss something? Hmm, wait, I guess someone could write code that reads/writes the session_values table without using the methods in the Session class, but that would be going out of your way to do something that will break, IMO.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,226
5/28/02 6:46:35 PM
|
You are now dependent on your table structure
I am not a PHP programmer, but if I understand what that is doing, it is safe because outside users cannot set arbitrary variables (the variables iterated over are the ones in the table) but you have opened yourself up to all sorts of confusing issues should new columns be added to the table, or should someone try to rebuild the table structure with fewer columns. (I have seen both.)
For that reason I like listing the fields that I want explicitly. That way if there is breakage, I find it faster. Plus it gives you something to grep for if you want to figure out where the variable got set.
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #40,295
5/29/02 9:42:36 AM
|
Should have been more explicit
Table structure is three colums: session_id, variable_name, variable_value, unique index on session_id, variable_name. Each session can set any arbitrary number or variables with any names. So I could have: | session_id | variable_name | variable_value | | 123456 | item | chair | | 123456 | color | red | | 123456 | price | 123.45 |
After the select query, the session object would have: $session->item = 'chair' $session->color = 'red' $session->price = '123.45' Makes carrying form values through a multi-page order process really simple. Just name all form values that need to be added to the session as array members ( <input type="text" name="data[item]">). When the session is built, it does: foreach($data as $key => $val){
if( !in_array($key,$reserved_names){
$query = "REPLACE INTO
session_values (session_id, variable_name, variable_value)
VALUES ('$sid', '$key', '$val')";
$db->Query($query);
}
}The array reserved_names contains any reserved words. Right now it's only username_display. ===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,312
5/29/02 11:39:36 AM
|
I would not be comfortable with that!
Do you know what a strange variable name could do to you? Read through what some strange variables in Perl do! (Change how you read input, match REs, lots of fun stuff.) Let alone if someone adds a new variable and doesn't realize that they should reserve it.
Basically you are now coding on the model of, "The user is allowed to do anything they want, and I will try to compensate." But what if you overlook something?
Also looking at that code, it looks like you are taking the customer's word on what the price of the item is. When a would-be cracker sees that the price is going back to the CGI script, one of the first things they will try is to upload their custom prices. Can they get a bargain? Oops!
You are reminding me of [link|http://www.perlmonks.org/index.pl?node_id=157252|this story], it is really bad and you didn't even realize it. You are putting their responses directly into the SQL without escaping them. That allows obvious and non-obvious attacks.
I just mentioned an obvious one. Here is a non-obvious one. Someone who knows what they are doing would try putting in various values that try to escape out of a string and then insert arbitrary SQL. A bit of playing around with the syntax and you have essentially handed over your database to anyone with the right knowledge and a little patience. This isn't an obvious attack, but it is bog standard, and unless you do something I don't see, you are vulnerable as all hell to it.
(And this isn't even getting at questions about how session IDs are created and validated. If you use a standard incremental ID system, watch out for users trying to guess and hijack neighbouring sesssions!)
Did I scare you yet?
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #40,314
5/29/02 11:53:39 AM
|
Yes, I am doing things I didn't show
Yes, I'm escaping inputs. I wasn't even looking at the actual code when I posted that, so it's quite a bit short of the real thing.
At some point, the input you get from a page has to go into the database, and you have to take all appropriate measures to prevent attacks. But, given that you are taking these precautions, is there any particular reason what I'm doing with variable-variables is a problem?
IOW assuming I do all the appropriate checks and nothging screwy goes into the database, is there any problem with how I get it back out and turn it into properties of the session object?
I realize there's the potential problem with using reserved words, but it's already bad practice IMO to use reserved words as variable names.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,452
5/29/02 10:25:54 PM
|
You're stopping short of a better solution.
I know PHP let's you create abitrary instance variables, but why are you doing it? Wouldn't an array be simpler? i.e. $session[$value].
Wade.
"Ah. One of the difficult questions."
|
Post #40,507
5/30/02 9:56:00 AM
|
6 of one, 1/2-dozen of the other
That just ends up as the difference between $session->name vs. $session[name]. At work I've got a similar class that provides both, because we've got some people who prefer each syntax. (No, no one is bothering to enforce a coding standard.)
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,659
5/30/02 11:50:47 PM
|
Slightly bigger difference
A hash is a private namespace. Now you don't have to worry about any possibility that your global variables conflict with the ones from the form. Much better.
I don't know what PHP offers in terms of iterating over a data structure, but it should also offer easy ways to iterate over your form variables should anyone want to do that. This is also a good thing.
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #40,699
5/31/02 9:14:47 AM
|
I must be missing something
A hash is a private namespace. Now you don't have to worry about any possibility that your global variables conflict with the ones from the form. Much better.
In my scheme, form variables end up visible as properties of the $session object. Namespace doesn't get much more private than that. Or am I misunderstanding you?
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,828
6/1/02 1:03:47 AM
|
I know what you're overlooking.
Dynamic instance variables are a feature of PHP that are really a side-effect of its dynamic variable rules. In short: they shouldn't work, but they do.
Hash tables are actually exactly what you should be using because that's what they were intended for.
Wade.
"Ah. One of the difficult questions."
|
Post #40,941
6/3/02 9:43:02 AM
6/4/02 9:26:11 AM
|
That could be nasty
Dynamic instance variables are a feature of PHP that are really a side-effect of its dynamic variable rules. In short: they shouldn't work, but they do.
Do they intend to "fix" this? That would break a few somewhat critical parts of my code. (Of course, I could always just rewrite the important lines to use eval() statements.)
[Edit was a typo]
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
Edited by drewk
June 4, 2002, 09:26:11 AM EDT
|
Post #41,062
6/4/02 6:16:32 AM
|
I don't know.
From a theroetical point of view, it would be nice to have it fixed. But the developers of PHP defend it and similar behaviour by saying that classes and objects in PHP are nice to haves. If it's on the ToDo list, it's down some way.
At least if you use a hash, you don't have to worry about whether the key is a legal variable name or not :-).
Wade.
"Ah. One of the difficult questions."
|
Post #41,071
6/4/02 9:07:57 AM
|
Out of curiousity
What could happen to him if a key was not a legal variable name?
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #41,244
6/5/02 7:01:46 AM
|
I don't know.
Knowing PHP, it would probably let you put almost anything in there. I say "almost" because I've seen hints in the comments in the online documentation that certain characters are used in the symbol table to flag "special" entries. Conflicting with those would be Interesting, to say the least.
Wade.
"Ah. One of the difficult questions."
|
Post #41,078
6/4/02 9:27:42 AM
|
So PHP supports hashes?
If so, then I should probably go read up on why they're so wonderful. Maybe if I understood exactly what they are I would see what Ben's been getting at a little easier.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #41,243
6/5/02 7:00:02 AM
|
Yes. It does.
They're called "arrays" in PHP and you probably already use them.
I can hear you going "huh?". PHP is the first language I've encountered that combines lists and hash-tables into the same data type. There are advantages, sure, but it's somewhat unorthodox. In most languages, they are separate data types. To use PHP's arrays as hashs, just use the $var['key'] format.
Wade.
"Ah. One of the difficult questions."
|
Post #41,255
6/5/02 9:33:11 AM
|
Blinding flash of the obvious
I use arrays like that all the time. In fact, the only difference in my code would be foreach( $result as $key => $val ){
$this->$key = $val;
} vs. foreach( $result as $key => $val ){
$this->variables[$key] = $val;
} ===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #41,018
6/3/02 7:29:53 PM
|
Stupid question?
As you know, I don't know PHP. So I am giving somewhat generic advice.
But still if the namespace is so private, then why do you have to worry about listing values to avoid? Conversely if you used a hash, shouldn't there be no possibility of conflict between the form and a list of private variables?
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #41,077
6/4/02 9:24:45 AM
|
Why there's names to avoid
Originally it was because user_id and user_display_name were key fields used in JOIN statements. Now, though, I am using session_id as the only key field, and joining user_id from the session table to the user table. I then create a user object that is a property of the session object. So now to get the user_display_name I use $session->user->user_display_name. Which means the only reserved names are session_id and user.
Yes, these changes were partly in response to the concerns you raised.
But still if the namespace is so private, then why do you have to worry about listing values to avoid?
So that I don't overwrite the user object with a variable of the same name.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #39,897
5/25/02 10:57:53 AM
|
Agreed
As I said, I'm not a professional programmer and usually don't code to deadline. Typically they're my own projects, where the idea is that I'm going to pass it on to our tech guy (who isn't a coder) with documentation to help him customize for future use.
Customization usually means editing a plaintext configuration file and leaving the main engine alone.
Yeah, I know...very UNIX-y...what can I say?
Tom Sinclair
"Subverting Young Minds Since 03/13/2000"
|
