[PHP] Functions internal to a class implementation
I have a class for elements of an HTML form and a bunch of subclasses for text box, radio, etc. I need some utility functions which will be called by some of the subclass implementations. These are utilities used within the class only, they are not methods. Is there a "best" way to implement this given that there are no private functions in PHP? The options seem to be to define the utilities globally, or define them as methods in the superclass and call them with superclass::func(); in either case I would never call them externally. Thanks for any tips, -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Password Authentication
I am trying to build password authentication into a database front end
for a MySQL DB. I find the php docs on this point quite confusing so I
have a lot of questions.
I can use a one-way hash to do this if that's the best way, as I don't
need to retrieve the password. However if I could do so that has some
small advantages. So I am open to either symmetric or one-way
approaches.
First off, there are multiple encryption methods out there -- PHP
crypt() and the mcrypt functions, and MySQL encrypt(), for encryption;
and the md5 etc. functions for hashing. Is there any information on
best practices here, particularly in using PHP's encryption vs MySQL's?
Second, the PHP docs on crypt are, to me, a mess. Much of it suggests
passing the password back in as the salt for crypt, but this appears to
me to only be workable if DES is being used and the first two
characters of the password are the DES salt value. Since the actual
encryption method is installation-dependent the code in the docs:
# You should pass the entire results of crypt() as the salt
# for comparing a password, to avoid problems when different
# hashing algorithms are used. (As it says above, standard
# DES-based password hashing uses a 2-character salt, but
# MD5-based hashing uses 12.)
if (crypt($user_input,$password) == $password) {
echo "Password verified!";
}
seems to me to be exactly wrong -- what it does is *create* problems
with different hashing algorithms. Using $password as the salt here
only works for DES, for md5-based encryption it will fail as the first
12 characters of the password are not the md5 salt (are they?). What
am I missing here?
Third, I am curious as to the repeated statements as to why one must
use a different salt every time. For example, here's a user comment on
the crypt docs from the PHP web site:
The only only important consideration when generating a salt
is to make sure that all salts are unique--that way the same
password will be encrypted differently (i.e. the encrypted
passwords will look different) for different users.
One of the simplest ways to generate a unique salt is to use
some string that will be different every time the procedure
is called. Here's a simple example:
$jumble = md5(time() . getmypid());
$salt = substr($jumble,0,$salt_length);
My question is, why would I do this? If you are going to save the
password you can't use a random salt without saving the salt along with
the password so you can test it later. And if you do that, the
randomness loses its value -- if someone breaks in and finds the
encrypted password, they also get the salt. Again, am I missing
something? Is there some potential attack where the attacker can use
the repeatability of the password encryption or hashing algorithm to
their advantage even if they cannot break into the server to see the
encrypted data? If not, and they have to be able to break in to do the
attack then, again, they can read the salt.
Thanks for any comments or input.
--
Tom Rawson
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Password Authentication
On 23 Mar 2003 Justin French wrote: > I just md5() the passwords, and reset them if needed... rather than > retrieving. The advantage for me on this is that it's portable... md5() is > part of the base PHP install, whereas the mcrypt stuff isn't (or wasn't). Something like that was my inclination as it seems simpler. One could also md5 the combined user / PW string, so the hash doesn't correspond to a single password. Do you know why there is all the stuff in the docs about using random salts? That didn't make much sense to me. -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Password Authentication
On 23 Mar 2003 Justin French wrote: > That's in the user notes... ignor it... md5() does not have to be salted... > infact, you WANT the md5() to be static... because you will compare the > md5()'d password in the database with the md5()'d password that they submit > on a form. Exactly. On this point the docs seem to be messed up. -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Removing Risky Characters
On 22 Mar 2003 David Otton wrote: > The thing that is most likely to trip you up is people who cut'n'paste > from Word. High-ASCII characters can slip in like that, also some > characters that are common in European languages (accents and umlauts). > All of these need to be translated into HTML entities. I understand that that needs to be done for display. My question was about input. What happens if someone enters an ASCII 147 or 148 in a form field, for example? Will PHP interpret them as quotes? Or is only an ASCII 34 seen as a quote. If the former, will addslashes() add shashes to them? -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Deleting Objects
How does one delete an object? For example: $object = new Class(...); . $object = new Class(...); I want to throw away the old object and create a new, freshly initialized one using the same variable. Is the above adequate or will this orphan the first object? If so is an unset($object) prior to the second "new" the appropriate approach? Thanks, -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Creating Session Variables
On 3 Apr 2003 CPT John W. Holmes wrote:
> No, $varname isn't created. You don't need it. You have a variable called
> $_SESSION['varname'], just use that where ever you need it (even within
> functions). If register_globals is on, you should be using the
> session_register() method, anyhow, not the one above.
I have register_globals off as that is (as I udnerstand it) a more
secure approach. ANd it will make hte code messy to use
$_SESSION['varname'] everywhere. I think I'll just copy it to a global
and use it that way.
Which leads to another question ... I thought these two constructs were
equivalent:
$var = "foo";
session_register('var');
.
$var = "bar";
$var = "foo";
$_SESSION['var'] = $var;
.
$var = "bar";
I would have thought that in both cases the session data saved at the
end of the script will have $var set to "bar", i.e. it is the value at
the end of the script, not the value at time of registration, that is
saved. Is this incorrect? The docs for session_register() left me
with this impression, and the general session docs suggest that
registering a variable with $_SESSION is equivalent to doing it with
session_register(), and in fact preferable. If they behave
differently, I can't see where the docs say so.
Thanks,
--
Tom Rawson
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing CCN's Again...
On 7 Feb 2005 Jochem Maas wrote: > > IE, is their a way to get PHP to overwrite the memory > > used by variables at the termination of a script? > > don't know about that but best not to accept the CCNs in the > first place. let the user enter it at authorize.net. I think this is an extraordinary (and unjustified) level of paranoia. The memory issue is moot on a dedicated server, and probably on a shared server as well. On a dedicated server if you can't control the access well enough to prevent unauthorized people from running programs to go poking through memory, you've got bigger problems to solve. On either kind of server the chances of finding a card number are remote to start with, and even if found it is likely to come with no associated address or cardholder information. Also there are far easier ways to get CC numbers than to hope one will be left lying around in memory. For one thing, a crook can generate CC numbers very easily -- the check-digit algorithm is published, and the bank ID numbers at the start I think are readily available as well. Of course many of those generated will be wrong, but there have to be enough right ones that a generated number is far easier for them to get than a number left lying around in memory. As for not accepting them on your own web page at all, I don't think commercial enterprises are obligated to go to a level of security that is that far beyond the norm, and it manifestly does not work in many site designs where the provider's page simply is not adequate or appropriate. The basic approach of using SSL from client to server and again from server to CC processor, and then not storing the full number, should be plenty good enough, and is for tens of thousands of commercial web sites. I have never heard of any signifcant problem with card numbers being stolen from sites operating this way, nor of any liability assigned by the CC companies to people following these (clearly industry standard) practices. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing CCN's Again...
On 8 Feb 2005 Jochem Maas wrote: > This was aimed at me. I personally wouldn't touch a CCN with a barge pole, > I did say it was 'best' not to accept them at all, although accepting them and > immediately passing them on via an SSL link (e.g. with cURL) is probably > 'good enough' - at least, apparently, 10,000s of merchant seem to think so. That was my point. Also you personally might not want to deal with them -- but would you always advise a client who hired you to develop a web site the same way? Or would it depend on their needs and concerns and the functions of the site? > >> cat /dev/mem | strings | egrep "^[0-9]+$" > > nice bit of magic tho, Greg :-) I agree, but to me the issue here is these two views: - "I have analyzed the need to accept credit cards and the risks of doing so. The risks are too great compared to the value so I will not accept credit card numbers on my site". - "I can imagine a way someone could gain access to them so I will not accept credit card numbers on my site." The latter is being confused with the former. The latter, to me, is not a good reaosn. The former is. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing CCN's Again...
On 8 Feb 2005 Jochem Maas wrote: > don't agree - I'd rather be cautious on a hunch, especially given that I > have no means to personally verify the risk other than in terms of total > financial ruin if a real problem occurs even once. besides its a moot point > there is no need to handle creditcard info in 99.999% of all cases > (the rest being covered by amazons,paypals,etc) Well OK, there is no urgent *need*. But accepting credit cards is a valid and useful approach for many sites. The worst-case imagined distasters do not make this less true. I cannot verify in advance that a car driven by a drunk driver will not drive down my street at the moment I walk out of the house, hit me on the sidewalk, and kill me. I do not *need* to leave my house in most cases, I could order almost everything I need to be delivered. But it still does not make sense to stay in the house all the time (and there are other dangers there anyway). The possibility of catastrophic consequences which you cannot control is not a reason to always opt for the most cautious possible approach. However I would agree it is a reason to thoughtfully assess the risks and make a choice. > then again there are +-2billion people with limited/no access to running > water... > maybe we shouldn't blow the CCN thing out of proportion :-/ Good point. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing CCN's Again...
On 8 Feb 2005 Greg Donald wrote: > It's pretty simple to scrub the data away. > > $cc = '1234123412341234'; > > // do processing > > $cc = md5( time() ); This only works if PHP uses the same storage for both strings. If it reallocates the storage, for example because the md5 result is longer, then the number may remain in RAM. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Multi-Page Forms
I have a form which is too long to be useful displayed on one page. I have it broken up into 7 sections. All 7 are generated by the same PHP source file, from data in a database. When the user updates a section they can submit it and go to the next section, or submit it and finish (return to a higher-level page). There is also a navigation form at the top that lets them jump from any section to any other, and uses JavaScript to prompt if they try to jump without having saved changes they made to the page. All of this is working fine. What's bothering me here is that when the user is done editing the data I use their input to regenerate a style sheet (the form allows them to customize the appearance of a web page for their customers). That's expensive -- relatively speaking -- in server load so I'd rather do it only once, when they're really done. But right now I do it every time they submit any page -- i.e. whenever any of the seven pages is submitted, the generation code runs. I don't see any simple way to let them jump around between pages, yet for me to know when they are truly finished with all the data. Of course I can give the required instructions -- "after you are done you have to click submit to save all the data" but I bet that those won't be read and the users will jump around, fail to save, and then complain that their changes are getting lost. Any thoughts on the design issues here? Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Foreach problem.
On 10 Feb 2005 Richard Lynch wrote: > Perhaps you need to use http://php.net/reset > > You see, when you do foreach or each or any of those, there is an > "internal" setting in the array that is altered to keep track of where you > are. Kind of like a big "You are here" arrow inside the guts of the > array. I believe this is incorrect. Or if not, the docs are wrong. From http://www.php.net/manual/en/control-structures.foreach.php: Note: When foreach first starts executing, the internal array pointer is automatically reset to the first element of the array. This means that you do not need to call reset() before a foreach loop. I don't know why the original poster had a problem, it seems mysterious so far, but it seems it probably wasn't for lack of a reset() call. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How do you read one of these parameters?
On 11 Feb 2005 Richard Lynch wrote: > BAD: http://example.com/dynamic_pdf.php?record_id=1 > GOOD: http://example.com/dynamic_pdf.php/record_id=1/fool_ie.pdf Just curious, how does IE screw up the first one? -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Session Vars and Performance
I have a multi-page form which I build up and store in session variables. The data saved includes all an internal list of items on the form (derived from a database table), all the form field specs (derived from the internal item list), the data for the fields (from another table), default data for restting the form (from yet another table), and a data structure for my forms class. It adds up to about 250KB in the actual session file -- that is, the serialized data. I'm not clear of the impact this will have in performance when it's in a multi-user environment, and I'm not sure at what point the overhead of serializing and unserializing gets to be more than the overhead of sticking this stuff in a temporary database table and then retrieving it. Serializing is simpler but my git says there has to be a point at which it gets inefficient. Testing is complex since I would have to write all the database code in order to do any performance measurement. Anyone have relevant experience in this area, and/or some educated guesses? Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session Vars and Performance
On 15 Feb 2005 Richard Lynch wrote: > Throw an ab (Apache Benchmark) test at it and find out. > > Don't just guess or sit there wondering. > > You could run test in about the time it took to compose this email -- Perhaps if you are already familiar with ab, which I'm not ... and if the server supports it, which it does not at this moment, development is on Windows, later testing and deployment on Linux. > All the database code is already written for you on the PHP > web-site, and it's about one 8.5x11 page of five (5) functions. > > Doesn't really sound like a complex test to me. The data is an internal list of items on the form, all the form field specs, the data for the fields, default data for resetting the form, and a data structure for the forms class. Most of these are in associative arrays, sometimes nested a couple of levels deep. If I'm going to build a database structure that mirrors the array structure, and update it every time the array changes during development, that's hardly straightforward. Without that, I'll have to serialize and unserialize the data -- and if I'm going to do that, I'd guess that I might as well use the session vars. So maybe that answers the question, and the remainder (below) is theoretical. > Sending the actual query and getting/storing the results will be > chump-change compared to opening the db connection, almost for sure. I do actually need a DB connection on every page anyway, so there's no benefit to avoiding one for this purpose. But to me the likely consumer of cycles here with a database structure matching the data structure would be the conversion of MySQL data into an associative array, and I'd be comparing that to serializing and unserializing. I don't think either is going to be trivial. > These two will be neck-and-neck on performance, and will depend more > on your hardware than on somebody else's experience with their > hardware. Fair point. > Particularly if you've got a 2-tier setup with database on one box > and PHP on another, where your network hardware and cabling gets > involved. Not in this case. > If you have to choose between a meaningful variable name and > performance considerations, buy more hardware! :-) Agreed! Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session Vars and Performance
On 15 Feb 2005 Greg Donald wrote: > > If you have to choose between a meaningful variable name and performance > > considerations, buy more hardware! :-) > > > > The cost you'll save in the long run for code maintenance will make it > > worth it. > > Comments in the code make using short session variable names a non-issue. Most of what's in my session file is data, not variable names, and my variable names are not particularly long. Descriptive, but not overly so (actually in this case most of the 'names' are associative array indices). If I shortened the variable names I might go down from 250K to 200K -- if that -- at a large cost in time for code modifications. I'm not at all keen on that approach, though I'm sure it might work for some. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session Vars and Performance
On 16 Feb 2005 Richard Lynch wrote: > Use the exact same session stuff you have now and just dump the > serialized data into SQL using the 5 functions for session handling. Oh, OK, that's what you meant about the 5 functions. I am not sure of the advantage to that, actually something I've always wondered. Especially if I am serializing the data anyway -- the way I see it is as follows (we are in the realm of theorizing here): Serializing is serializing, likely just as fast whether using the built-in session mechanism or a replacement, or even serializing it myself, I'm sure it all goes through the same underlying routine. Writing and reading a single flat data record like this through MySQL has to be slower than using a flat file, unless PHP flat file access is somehow drastically slower than it should be. Ergo, I'm likely to lose, not gain, by using MySQL. (So why did I ask the original question? Because I hadn't analyzed it this carefully first!) > It's literally an hour's work to alter the code to use MySQL to store the > sessions instead of the hard drive. > > This might or might not improve performance. As mentioned above -- under what circumstances would it improve? Perhaps if file open is an expensive operation and the database is already open. But it's hard to think of where one would expect the SQL access to be faster. > It's incredibly UNLIKELY that trying to send an SQL query for every single > line of code that currently does $_SESSION[...] = ...; is going to be > faster... I'd almost be willing to say IMPOSSIBLE that would be faster, > but somebody would post a trivial example to prove me wrong :-) Totally agree. > But you'd probably find it easier to write a C extension and > re-compile PHP to pre-load all the stuff. > > None of which applies to you, I don't think, but you may want to > re-read that thread. Well when I am not doing PHP programming I do C and C++ programming so I could conceivably do that, but have no desire to -- and my client certainly wouldn't want to pay for it! -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Data Encryption
On 2 Mar 2005 Erbacher Karl wrote: > I'm not sure if this is even a PHP question, but I'm hoping someone can help > me. I need to encipher data to be stored in a database and then I need to be > able to decipher it to use it. I was thinking of using DES and I obtained a > pair of keys, but I'm not sure where to go from there. I've scoured the > internet for help, but I just can't figure out which is the best way to do > what I need to do. You could look at http://www.php.net/manual/en/ref.mcrypt.php. mcrypt supports a long list of ciphers, including triple DES. I usually Blowfish for the purpose you describe, though I can't remember exactly why right this second -- I did some research at one point and concluded it was the best for my purposes. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Consulta
On 4 Mar 2005 J. L. Marcelo Chaparro Bustos wrote: > Hola, bueno acabo de incribirme el la lista y queria saber si alguno > de ustedes tiene un manual PHP basico que me pueda enviar o decir > donde poder bajarlo, para orientarme un poco. gracias Translation: Hi, I just joined this list and I wanted to know if anyone had a basic PHP manual that you can send me, or if you can tell me where to download it, so I can get oriented. Thanks. Answer: Los documentos basicos son disponibles en español en http://www.php.net/manual/es/, y puede bajarlos en la forma ".html.gz" de un sitio en Chile en http://us4.php.net/get/php_manual_es.html.gz/from/cl.php.net/mirror. The basic documents are available in Spanish at http://www.php.net/manual/es/, and you can download them in ".html.gz" format from a site in Chile at http://us4.php.net/get/php_manual_es.html.gz/from/cl.php.net/mirror. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Problem with Tabs and Newlines
On 7 Mar 2005 Jay Blanchard wrote: > /t and /n do not work for HTML output. If you view the source of your > HTML output you will see that the tabs and newlines are used properly. > You will have to substitute an HTML equivalent. The HTML equivalent would likely be tables -- but if he uses then the tabs and newlines should work. For the original poster -- in other words, near the start: $row = "Filesystem\t" . "Size\n"; and near the end: $row .= "\n" If you don't mind the monospaced font then that should work -- though you are at the mercy of whatever the browser uses for tab spacing. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password Boxes
On 14 Mar 2005 Ross Hulford wrote: > Does anyone know how to change the style of password boxes so when > the characters are entered an asterisk appears rather that a smal > circle? It is determined by the browser and OS. I presume you are talking about Windows XP, which is where I see that behavior. You might try use a CSS entry or "style=" to change the font for the input box to Courier and see if it behaves differently. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password Boxes
On 14 Mar 2005 Dotan Cohen wrote: > change > > > To: > This does not address the question. The OP saw small dots in the password display, he wanted asterisks. That is not because he was using type='text' but because he was already using type='password' and the browser had a particular way of displaying characters in such fields, which he wanted to change. > This is an HTML related question, not php (or even javascript). Next > time try google. Really it is a browser implementation question, not even HTML. But in any case, I am not the person who asked the question. You may want to direct your advice to them. People get confused all the time about what is happening on the server side and what is on the client side. This poster asked specifically whether the issue could be addressed in PHP or was (in his terms) an "OS issue". I don't think knowing the answer to that question is a prerequisite for posting here. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Auto logout
For the basic logout, it's very easy. Store a session variable which is the "last active time". Initialize it to the current time when the user logs in. Each time a page loads, start the session and check current time against the last active time. If the difference is over the limit, display a message and/or go back to the login screen. If it is not, reset the last active time to the current time. This way you have a timer which is reset on every page load. If no page is loaded for some given amount of time, the timer "expires" and you force a new login. To update the logged in status in the database after a time-based logout, you need a way to know when the user has *not* done something, and that by definition is not going to come from the user themselves. So you have to use a cron job which resets the database flag, there's no way around it. You could store the "last active time" described above in the database in addition to or instead of in the session data to facilitate this. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Getting the process ID
On 24 Mar 2005 Joshua Beall wrote: > I realized that this sort of problem would always exist unless I had some > sort of semaphore mechanism. Once a user has *started* a transaction, they > need to be prevented from initiating a second transaction until the first > transaction has been completed. Why not simply store some kind of user ID and a timestamp for the transaction start time in a database. Every time a new transaction is started check the database, if there is another one in process, give an appropriate error. When the transaction completes delete the record. The hole in this of course is transactions that start and never finish. That's why I suggest a timestamp -- you can use it to check how long it's been since the previous transaction started, and ignore it if that's over some threshold (for example, if the previous transaction was stated a minute ago and a normal transaction takes 5 seconds, you can be pretty sure). And you can run a cron job to periodically sweep the database and remove old transactions that never completed. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Getting the process ID
On 25 Mar 2005 Joshua Beall wrote:
> P1: "Does token.status = 'locked' WHERE key=$key ?"
> P2: "Does token.status = 'locked' WHERE key=$key ?"
> P1: {Receives negative response}
> P2: {Receives negative response}
> P1: Updates token.status. = 'locked' WHERE key=$key
> P2: Updates token.status. = 'locked' WHERE key=$key
The problem here is that the check / lock operation has to be "atomic",
that is you can't let a second process check or lock the resource while
the first is in the process of locking it. This is a basic issue for
any kind of semaphore, you have to be able to do an atomic "test and
set" or you get problems exactly as described above.
If it's a MySQL table then to me the simple solution is to use a LOCK
TABLES then test and set the token stored in the database, then UNLOCK
TABLES. But that might be a bit "expensive" in terms of overhead, and
you can probably find a way to do it with local files as well. Also
the shared memory functions look like they could be useful in this
regard, if supported on your platform.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] parsing values from a form post
On 8 Apr 2005 Chris Bruce wrote:
> I need to be able to break out the tax, amount and type that were
> entered on each line of a form and then apply calculations and do
> database inserts on each. As you can see what I need is in sets of
> three denoted by the integer at the end (tax0, amount0, type0, tax1
> etc.)
>
> I can't figure out how to separate these variables and values so that I
> can do what I need to do.
The other suggestion is a good one but if you want to do it with the
variables as you named them you can also use something like this:
for ($i = 0; $i < $maxlines; $i++) {
$tax = $_POST['tax' . $i];
$amount = $_POST['amount' . $i];
$type = $_POST['type' . $i];
.
}
There is more one should usually do here, for security -- anything
coming in via _POST should be processed through functions designed to
remove malicious data. For example, an approach something like this:
$value = strip_tags((substr(trim($_POST[$fldname]), 0, MAX_LEN));
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing password in cookie
On 9 Apr 2005 Andy Pieters wrote: > It doesn't matter how you encrypt it. > > DO NOT STORE PASSWORDS ON USERS COMPUTER > > I hope that's clear enough. A couple of people have stated this but I think it is incorrect. For one thing the users themselves are very likely to store the password there, so why shouldn't you -- with permission of course? Many sites will do this with a "remember my password and log me in automatically" feature. Web-based discussion boards, for example, do this routinely and the only security risk is that someone who got access to your computer might get access to your account on the board. As long as the discussion topics are not sensitive I suspect most people using private computers would judge this to be an acceptable risk. On the other hand I would never do it (or allow a site to do it) for a site where my email account could be accessed, or money could be charged. But others might feel their computer is secure enough that they are willing to take even those risks. Like many such questions, to me this is not something that should be subject to absolutes but to considered judgment, some on the part of the developer and some on the part of the user. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing password in cookie
On 9 Apr 2005 John Nichel wrote: > While it is not absolute that you can't store passwords in a cookie, it > is an absolute that you _shouldn't_ Sorry, I don't agree. There are very few absolute rules in software development. For sites accessing sensitive information or that allow spending money, I would not store anything in a cookie that permitted a login. However, for something like a web-based discussion board where I don't really care if a person who sits at my computer or a thief who robs my house gets access, I think it is not a big deal. I might, depending on the needs, store a hash code as others have suggested, or an encrypted version of the password, with user permission of course. There is almost always a tradeoff between convenience and risk. Sometimes convenience is far more important. Often risk is. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing password in cookie
On 9 Apr 2005 Jason Wong wrote: > > I might, depending on > > the needs, store a hash code as others have suggested > > Why not in *all* cases? Well, just because I'm not sure it is worth the effort. What is the point of storing a hash code as a proxy (in the colloquial sense of the word) for an encrypted password if knowing the hash code gets you the same access as knowing the password? True, the hash code can have a timeout -- but so can the cookie. For places where the point of the PW is authentication only, and not control of access to significant resources, I'm not sure there is any benefit to complicating things. > I can't see where the convenience lies. For you as a developer, you've > already got the necessary code to do the token thing so there is > practically no difference whether you use a token or a password. For the > user, what are they going to do with an encrypted password -- are you > going to tell them how to decrypt in the case that they have forgotten > the password? A fair comment. I guess it is more just about keeping things simple where appropriate. Just as an FYI, I'm partly playing devil's advocate here. I've never written anything that stored the encrypted PW in a cookie (though I have stored encrypted user IDs that way for a "remember me" feature). I'm just reacting to the sense that there is One True Way to handle this issue. In software development there are most often many good options. A digression to a related issue (where I did take the conservative approach): A system I'm working on now was originally set up with password hashes in the database -- the PW itself was never stored. But the client wanted an "email me my password" feature so we had to encrypt and store the PW. Of course if someone had access to the database they'd get a lot of other stuff probably more useful than PWs so I don't worry about this too much. But I would rather have used the hash. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing password in cookie
On 9 Apr 2005 Ryan A wrote: > This certainly has turned out to be an interesting discussion.I > usually send the info via sessions...how bad is that? Well if you are using sessions it is worth thinking about session security, for example: http://shiflett.org/articles/the-truth-about-sessions http://www.acros.si/papers/session_fixation.pdf Beyond that -- what info are you sending?? Session data is stored on the server, not at the client, so the security is as good as for anything else on the server (assuming of course that session data is outside the web document tree). Personally there is little if any data that I would encrypt when saving it as session data (maybe CC numbers, if I had to save them across pages at all, or maybe passwords, but nothing else), because I think that's a weak defense. If access to your session data means they have gained access to the server then they can also find the code you use to decrypt that session data, so it is just one more small obstacle, not a true defense. Another point is that this might require a different analysis on a shared vs. dedicated server as a shared server may well be less secure than a dedicated server, and a dedicated server you don't physically control (e.g. colocated) may be less secure than one you do. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing password in cookie
On 11 Apr 2005 Richard Lynch wrote: > > Well, just because I'm not sure it is worth the effort. What is the > > point of storing a hash code as a proxy (in the colloquial sense of the > > word) for an encrypted password if knowing the hash code gets you the > > same access as knowing the password? > > Because the hash code will change VERY frequently. Fair enough. And I also take all the points about plaintext passwords. I don't think anyone was talking about that (I certainly was not). > You have to assume the user of the PW has been stupid and set the PW > to the *same* PW as their bank account. Fair enough. The approach I was talking about does not protect against that and that is a flaw. The random token approach does a much better job. > > Just as an FYI, I'm partly playing devil's advocate here. I've never > > written anything that stored the encrypted PW in a cookie (though I > > have stored encrypted user IDs that way for a "remember me" feature). > > I'm just reacting to the sense that there is One True Way to handle > > this issue. In software development there are most often many good > > options. > *WHY* would you not store some kind of hash of the user ID?! Because in that particular system no one considered the user ID to be valuable. It is a little more complex to store and look up a hash, but not dramatically so. > > A digression to a related issue (where I did take the conservative > > approach): A system I'm working on now was originally set up with > > password hashes in the database -- the PW itself was never stored. But > > the client wanted an "email me my password" feature so we had to > > encrypt and store the PW. Of course if someone had access to the > > database they'd get a lot of other stuff probably more useful than PWs > > so I don't worry about this too much. But I would rather have used the > > hash. > > Please tell me what URL that is. I want to BLOCK it so I never ever ever > visit it. Thank you. > > Even my lowest-level stupidest password for the 10,000 sites I don't care > about shouldn't be stored in clear-text ! Who said anything about *storing* the PW in clear text?? For the record, it is stored encrypted, though I know this is weak protection since access to the server gets you access to the decryption key. For the web portion of this there is no visibility to the password at all. For the email portion, of course there is as the password has to be sent in clear text as it is useless otherwise. I personally would prefer to use a "Reset my password" approach and display the new PW over an HTTPS connection, but that does not meet my client's needs. And "Email me my password" features are widespread -- used most often on web-based discussion boards and the web-based interfaces for mailing list software. Are you saying they are all wrong and no one should develop or implement them, or just that you personally would never use that feature? On the general issue -- there are sites with login security practices that are excellent, good, mediocre, poor, or nonexistent. What's bugging me here is not the idea that we should know about and use good practices, and from being willing to put forward my own questions I've learned a lot about that in this discussion. What's bugging me is that there is a tone suggesting that everyone should be using the highest- level security practices for all data no matter how unimportant. I have always learned that you match the security practices to the value of the assets protected and the level of threat. A shed in my back yard should be locked but it does not need an alarm system tied to the local police. My house might. The local bank should do way better than that. Etc. Web site security has the added problem that we do allow people to use the same key for the bike shed and the bank, but beyond that there are still tradeoffs and decisions to be made and not everything requires the same degree of protection. Also I think it is easy to forget about the difference in the level of threat posed by a routine vs. rarely or randomly used feature. If an encrypted password is stored in a cookie every user of the site is vulnerable and the entire universe of user accounts is open to attack if someone can figure out how to decrypt it. On the other hand an "email me my password" feature is only open to attack when used and for the people who use it. The number of systems or events which it produces for attack is much smaller. That doesn't make it secure but it is likely less of a threat than practices which create vunerabilities automatically on every system which connects to the site. This kind of discrimination seems to often be absent in the discussions here, but when implementing seurity in a real system I contend you have to do it. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] validating input
On 12 Apr 2005 blackwater dev wrote:
> $good = "joh_'";
>
> // Let's check the good e-mail
> if (preg_match("/[a-z0-9]/", $good)) {
> echo "Good";
> } else {
> echo "Bad";
> }
>
> This returns Good, why?
That regex matches any string which contains at least one (lowercase)
letter or one number somewhere within it. To match for only those
elements and no others you probably want:
if (preg_match("/^[a-z0-9]*$/", $good)) {
which will match a string which contains nothing but a-z and 0-9, and
will also match the empty string. See
http://www.php.net/manual/en/reference.pcre.pattern.syntax.php and look
at the meanings of ^, $, *, and +.
Other variations for the regex:
/^[a-z0-9]+$/ as above but will not match empty string
/^[a-z0-9]*$/i as above but matches upper case as well
/^[a-zA-Z0-9]*$/like previous line -- as above but matches upper
case as well
As Chris S. pointed out, a regex is not needed for this task, so the
above is just academic.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing password in cookie
On 11 Apr 2005 Chris Shiflett wrote: > > > DO NOT STORE PASSWORDS ON USERS COMPUTER > > > > A couple of people have stated this but I think it is incorrect. > > Please refrain from such speculation, because it does nothing to improve > the state of security within our community. This idea of storing > passwords in cookies is absurd. Hmmm, sorry, it wasn't speculation but an opinion in response to what I thought had moved from a practical into a theoretical discussion. I agree, storing even an encrypted password in a cookie is a poor idea in most situations. But to me development is about selecting the right tool and using it the right way for the job at hand, and as a matter of principle I'm not convinced that a password stored in some form in a cookie can never, ever be the right tool for any job -- even if it's the wrong tool for many or most. As I said in other posts, there is a tendency here to declare certain practices as "the one and only way", but I think development is almost always more complex and more of a balancing act than that. If the discussion of that balance is beyond what the list is for and there is a need for a simple rule that everyone can follow then I certainly agree that "don't store passwords on the user's computer" is a far better rule and promotes better security practices than "it depends". But as I said I thought the discussion was more theoretical at that point, and that that was equally part of what's discussed here. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] RegEx help
On 15 Apr 2005 Tom Rogers wrote:
> BD> a. Must contain an 1 uppercase letter. [A-Z]
> BD> b. Must contain 1 digit. [0-9]
> BD> c. Must be a minimum of 7 characters in length. {7}
>
> BD> I'm not sure of how to build the correct syntax for using all 3
> BD> requirements together.
> easier done seperately I think
> if(
> strlen($text) > 6 &&
> preg_match('/\d+/',$text) &&
> preg_match('/[A-Z]+/',$text)
> ) { echo 'OK ';
To do it in one fell swoop you need to use lookahead assertions --
something like this:
if (preg_match('/(?=.*[A-Z])(?=.*[0-9]).{7,}/', $text))
echo 'Valid!';
I believe this matches for any string that has at least one uppercase
letter and one digit and is at least 7 characters long. However it
allows other characters as well (not just A-Z and 0-9). Lots of
possible variations there.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing password in cookie
On 13 Apr 2005 Richard Lynch wrote: > I have what I consider a MINIMUM standard level of security for any site > that asks for a password. > > That would include: > Not storing the password *ANYWHERE* in clear-text. > Not in database. > Not in $_SESSION > Not in COOKIES Agreed. I see less risk for temporary storage in $_SESSION in the case where the server is well-protected logically and physically, but it's so easy to encrypt (if session storage is needed at all) that there's no reason not to. > Not storing an encrypted username/password in $_SESSION/COOKIE if having > those values provides access. Because at that point, the encryption is > rather meaningless, as it's really a clear-text 32-character code that > happens to be the encrypted value of something secret, but the clear-text > 32-character code gives the Bad Guy access, whether they know the secret > or not. > > If your content/application/data is important enough to warrant a > username/password, then it should be important enough to secure with this > minimal level of security, IN MY OPINION. Here I think we disagree as by this logic no one should store anything in a cookie that provides access (beyond a short temporary timeframe). There are many kinds of sites where users want some privacy or control over their own account but also want the convenience of staying logged in, and where there is little or nothing any Bad Guy skilled enough to go steal the cookie would bother with. For example, many discussion board logins fit this description. I personally use a different password for each one I'm on (it's not very many), and far prefer the convenience of not having to go look it up every time over the "security" of having it expire, particularly since the very worst someone can do if they gain access is post as if they were me. The analogy is that the Bad Guys who know how to break into bank vaults just don't care about my (hypothetical) shed full of garden tools, and if they do test their skills there, the garden tools aren't that valuable anyway. And if in order to prevent this highly unlikely theft I have to remember my key every time I go out to do some work, that's a poor tradeoff to me. What we're arguing about is whether the garden shed [web site] should be designed so that I *have* to use a key (i.e. require a specific level of security) or whether I as the user can choose. For anything involving money or significant personal data, or other similar risks, yes, to me the login security should be forced. But for less important assets there are real benefits to security practices that give the user more control. Some of this is simply a question of whether there is a category of stuff that is important enough to protect with a password but that doesn't require more careful security, login expiration after a short time and other protection mechanisms. I think that category exists, sounds like you are saying you think it does not. > If users forget passwords, they should get new random passwords, with the > application/email directing them to change those passwords to memorable > (to them) but hopefully un-guessable (to Bad Guys) values. Agreed. My clients don't always agree but I think this is correct. > I would contend that anything less is simply a false sense of security, > provided to the un-informed, by using inherently insecure > username/password methodolgy. > > The fact that 10 zillion sites are currently doing exactly that does not > make it "right". > > You obviously disagree, and think everything is just hunky-dory in the 10 > zillion sites that are leaking passwords to any Bad Guy with half a clue. Well I hope that was a bit tongue in cheek. I didn't say that nor do I think that. There's a lot of bad security out there. That doesn't make someone like me who disagrees with a particular set of security principles into someone who thinks all bad security is fine. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Storing password in cookie
On 14 Apr 2005 Chris Shiflett wrote: > When a user enters a credit card number, there may likely be a > verification step before the actual purchase is made. It's better to > keep this number on the server (in the session data store) than to > unnecessarily expose it over the Internet again (SSL mitigates the risk, > but an unnecessary risk is still worth avoiding). > > Being mindful of this, it's also helpful to not even display it to the > user, instead showing only the last four digits or something, because > this display also counts as exposure (since it's in the response). There is one case where redisplaying the number (via https) makes sense to me -- when it fails a verification check. The obvious example is a simple check-digit error due to a typing error on the user's part. In this case the option is either expecting the user to retype the entire number every time they make a mistake, or accepting the -- to me minimal -- risk in sending it back for editing when redisplaying the form and error message. But doing that does require putting the CC # in some form into session storage (or some kind of storage) in the case where the processing / validation and display scripts are separate and the processing script needs to pass posted data back for redisplay. Re last four digits, I have notice that many sites seem to be going to showing the last five or six, first four plus last four, etc. Apparently people are finding that last four alone isn't sufficient for users to recognize the card. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Font color
On 16 Apr 2005 Ryan A wrote: > eg: if they pick white I need the heading to be black and vice > versa...any way to do this? Well it depends what you mean by "opposite", but as a starting approach I would try simply complementing the bits in the RGB value: $opposite_color = $original_color ^ 0xFF; This will yield, for example, all of the following, and their inverses: #00 => #FF (black => white) #FF => #00 (red => cyan) #00FF00 => #FF00FF (green => magenta) #FF => #00 (blue => yellow) -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Font color
Here is a little code that shows the "web-safe" colors and their
"opposites" using the algorithm I described in the previous message:
");
print("\n");
print("Color\n");
print("Color swatch\n");
print("'Opposite' swatch\n");
print("'Opposite' color\n");
print("\n");
foreach ($weblist as $red) {
foreach ($weblist as $green) {
foreach ($weblist as $blue) {
$hexcolor = $red . $green . $blue;
$hexoppcolor = sprintf("%06X",
(hexdec($hexcolor) ^ 0xFF));
print("\n");
print("#$hexcolor\n");
print(" \n");
print(" \n");
print("#$hexoppcolor\n");
print("\n");
}
}
}
print("\n");
?>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: A question
On 16 Apr 2005 Khorosh Irani wrote: > How I can find it in phpinfo() ? Another (simpler) approach is: echo php_sapi_name(); which will return 'cli', 'cgi', etc. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] round?
On 16 Apr 2005 Chris Knipe wrote: > I'm not sure if round() is what I am after. I want to round whole numbers > to the closest 10 - thus, not decimals, etc. Just use a precision of -1. For example round(125, -1) will return 130. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Replacing spaces with commas
On 17 Apr 2005 W Luke wrote:
> I have about 200 records in a table, and I need to update 2 of the
> fields. The first is easy, but the second contains a list of keywords
> all separated by spaces; I need to replace the spaces with commas. Is
> this something I can do with some clever SQL, or shall I just do it in
> PHP?
Well I have not used this function, but it looks like it would do what
you want (this is from MySQL):
REPLACE(str,from_str,to_str)
Returns the string str with all all occurrences of the string
from_str replaced by the string to_str
So for example:
REPLACE(field, ' ', ',');
In other words, how about a query like this:
UPDATE table SET field=REPLACE(field, ' ', ',');
I have not tried using a function in an UPDATE statement like this but
you can test it and see, I would expect it to work.
In PHP you can do the same thing -- load the data with the mysql_
functions, then:
$newval = str_replace(' ', ',', $oldval);
then use UPDATE to put $newval back into the database.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PHP-WIN] Localhost not working with cookies
On 18 Apr 2005 Proudly Pinoy wrote: > I've read from php.net/setcookie and codecomments.com that using > localhost won't work with cookies and neither are IP addresses. So > how do I test cookies on local system? Hmmm, this works just fine for me -- I do it all the time. I tend to do it with a domain mapped to 127.0.0.1 via the hosts file, rather than "localhost", but using that approach I can set cookies fine under Win98 (as far as I remember, not using it now), Win 2000, and Win XP, in both Mozilla and IE. I am running Apache 1.3.29 as the local server in all cases. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] reverse MD5 ???
On 21 Apr 2005 Jason Barnett wrote: > Any information that you wouldn't want in the script in plain text, you > probably don't want in the database in clear text. Moreover MD5 is a > one way hash and although it is broken, you probably don't want to spend > the processing time needed to reverse it. In the general case, no reasonable amount of processing time will reverse it since (AFAIK) you have to brute force test all possible values, though for very short text it can sometimes be done, and there are online databases out there. For the OP, this is part of what it means to use a hash or digest (MD = "message digest") as opposed to an encrypted value. The conversion from the original text to the hash is one-way and as a general rule cannot be reversed except by trying every possibility for the original text, which becomes an astronomical task with even very small text lengths. For example, for text using a-Z, A-Z, and 0-9, there are 218 trillion possible 8-character values (62 ^ 8) and 839 quadrillion possible 10-character values. Imagine MD5 (this is a very crude analogy) as taking a letter, tearing it up into tiny pieces, rearranging them according to some complex predefined algorithm, then selecting a hundred or so pieces with individual letters on them and putting those together as a code, and burning the rest. There is no way you can reproduce the letter from the code, except in the limited case where the letter is very short and your code actually incorporates all the pieces. I believe the places where MD5 can be broken by brute force are where common words or phrases are used -- then it is possible to create a database of possibilities and their MD5 hashes and the database lookup is then quite fast. For example this allows people who have the MD5 hash of a password to break short, common words used as passwords very easily. But if the MD5 value is not there, you are still stuck. For the example above (10-character values using A-Z, a-z, and 0-9) if my calculations are correct it would take about 32 million gigabytes to store those 839 quadrillion values and their matching MD5 digests in a database, not counting indexing (which adds to this) nor compression and other optimization (which could reduce it). I am not talking about general security here and saying it is OK to expose the MD5 values, just looking at the difficulty of reversing them. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] reverse MD5 ???
On 21 Apr 2005 M Saleh EG wrote: > It's simple. > If your system supports it performance wise. > Grab the id and compare it against the md5 version of the id saved in the > cookie. Actually I think the discussion was about reversing the MD5 to get back the original message -- not about cookies or IDs. What you are discussing is a different issue. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: reverse MD5 ???
On 21 Apr 2005 Greg Donald wrote: > > Same thing with MD5, it > > is just one way, it can't be reversed. > > MD5 collisions were found last year: > http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf > > Just a matter of time/cpu power. I don't think that's right. Collisions allow certain kinds of cryptographic attacks against things like MD5-based signatures but that is not at all the same as being able to simply determine the original message content from the digest. Rather, they allow you to substitute the original message with a different one which generates the same MD5 hash. This may or may not be useful as an attack, depending on how MD5 is being used. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: reverse MD5 ???
> > It's more like a theoretical "hole" that may some day prove to be the > > first step in a long long long process of understanding something that > > might maybe some day yield a way to de-crypt MD5. > > That's exactly my point. > > It's similar to how a local root exploit sometimes evolves into a > remote root exploit once publicized and people begin working on it. > > Disclaimer: There are only about 5 or 6 people in the entire world who > know anything about encryption.. and sadly I am not one of them. MD5 is hashing which is not the same as encryption. Hashing is normally defined as a one-way conversion of a plaintext message into a fixed-length digest or "hash". Encryption is normally defined as conversion of a plaintext message into ciphertext which cannot be read until it is decrypted -- i.e. encryption normally implies the possibility of decryption. In that framework there is no such thing as "decrypting" an MD5 digest, because an MD5 digest is not an encrypted version of the message to start with. No amount of CPU power will change this basic fact -- though CPU power can be used to do a brute force search for strings which will generate a given MD5 value. However, as stated before, at current levels of computing power this is not feasible for messages beyond I think 7 or 8 characters long (don't quote me on that). The recently discovered "hole" is unrelated to the above. It is that under certain conditions it is possible to find two different plaintext messages which will generate the same MD5 digest. This could theoretically allow one to spoof a message and have it appear legitimate if MD5 is used for the legitimacy check, but it does not allow "reversal" of MD5, nor do the authors of articles on this problem seem to claim that it could. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Fastest templating mechanism
On 8 May 2005 Evert | Rooftop Solutions wrote:
> What I really need is a fast lookup mechanism, to 'translate'
> statements.
>
> For example:
>
> setOutputType('xhtml');
> echo(translate('authorstart'));
>
> the function translate opens xhtml.data, which contains:
>
> authorstart :
> authorend :
>
> so, the translate function looks 'authorstart' up and returns ' class="author">'
>
> or if you had specified 'wml' as the outputtype, the file could like like:
>
> authorstart :
> authorend :
>
> and the function would return ''
>
> This is all no problem, except that these lists can be pretty big. And I
> wouldn't like to load them all into the memory, or have to loop through
> the file every time translate is called.
>
> So I need a very fast mechanism to overcome this problem.
I think it's called a database. The fields are outputtype, key, and
text to output, with an index on outputtype + key, then you do
something like this:
select OutputText from TranslateTable where OutputType = 'wml'
and key = 'authorstart';
I wonder how many of these you really have. If on each script
invocation you will be looking up many of them (dozens or hundreds) it
might be more efficient to load all the ones for the outputtype you are
using into a PHP array at the start, whether that's in a hard-coded
array or loaded from the database. If you're only looking up a couple
then a separate database lookup for each one is probably more
efficient.
Incidentally I would say this is not a templating problem. It's simply
a translation or lookup problem.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Fastest lookup mechanism
[Note that I changed the thread title to reflect that this isn't really about templating.] > Yes I thought of this, but in my case a flat file would be better. The > same problem applies though: > [quote] > This is all no problem, except that these lists can be pretty big. And I > wouldn't like to load them all into the memory, or have to loop through > the file every time translate is called. > [/quote] I don't understand your comments. Why would a flat file be better? Unless you have fixed-length lines and a sorted file so that you can do a binary search, a database is going to be several orders of magnitude faster than a flat file. Look, fundamentally you have a simple problem -- to find a needle in a very well-defined, orderly haystack. This is a problem that many people have solved in the past and for which very robust solutions exist. Those solutions are things like tree search, binary search, and hash table lookups. An indexed database might use any of these, arrays in memory use hashing. So these solutions exist but it seems you are saying "I cannot use any of those, I need to use a flat file, now tell me how to make it fast enough to be able to do perhaps hundreds of lookups per page". My guess is you simply can't meet that goal with nothing but a flat file, unless your standards for page display time are very low. The best way to make it faster is to convert your flat file to a database and/or load it as an array. So my first question is, *why* are you objecting to these tried and true methods of answering exactly the question you are asking? If you must use a pure flat file, the fastest search method I know of is to maintain it in sorted order with fixed-length lines and then do a binary search. Algorithms for this are readily available if you are not familiar with the technique [a great if expensive source for algorithms of this type is the classic book "The Art of Computer Programming", volume 3, Searching and Sorting by Donald E. Knuth]. But binary search on a large flat file is still likely to be unacceptably slow for hundreds of lookups per page. Caching will help but you will have the exact same problem with the cache -- how do you find the data you want within the cache? -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Most bizarre date problem ever
On 10 Apr 2004 Brian Dunning wrote: > Check this out: I'm returning a list of the last 30 days, looping > through i, subtracting it from $end_date where $end_date is 2004-04-10 > 00:00:00. I'm just trying to derive a timestamp $check_date for each > iteration, like 1081321200. Here's the code within the loop: > > $check_date = mktime(0, 0, 0, substr($end_date, 5, 2), > substr($end_date, 8, 2) - $i, substr($end_date, 0, 4), -1); > > Note that this works PERFECTLY for every date, and always has. Except > for one particular day. When $end_date - $i is supposed to be April 4, > the timestamp returned is -7262, which it thinks is 12/31/1969. I don't see the same problem. This code: Produces this output: 1081483200 = 04-09-2004 1081396800 = 04-08-2004 1081310400 = 04-07-2004 1081224000 = 04-06-2004 1081137600 = 04-05-2004 1081054800 = 04-04-2004 1080968400 = 04-03-2004 1080882000 = 04-02-2004 1080795600 = 04-01-2004 1080709200 = 03-31-2004 1080622800 = 03-30-2004 1080536400 = 03-29-2004 108045 = 03-28-2004 1080363600 = 03-27-2004 1080277200 = 03-26-2004 1080190800 = 03-25-2004 1080104400 = 03-24-2004 1080018000 = 03-23-2004 1079931600 = 03-22-2004 1079845200 = 03-21-2004 1079758800 = 03-20-2004 1079672400 = 03-19-2004 1079586000 = 03-18-2004 1079499600 = 03-17-2004 1079413200 = 03-16-2004 1079326800 = 03-15-2004 1079240400 = 03-14-2004 1079154000 = 03-13-2004 1079067600 = 03-12-2004 1078981200 = 03-11-2004 Tested on PHP 4.3.4 on Win2K. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Using unset with $_SESSION
I am trying to find a reliable method to clean out all session variables and start clean. Running PHP 4.3.1 on Win2K developing a web app to run on Linux. Session cookies are enabled, register globals is off. I access all session variables with $_SESSION. What I have found is that if I use unset($_SESSION), set a single variable, and redirect, the OLD session data is passed to the new page. However if I use session_unset() or $_SESSION = array() and set my single variable, the data is passed properly. Shouldn't unset($_SESSION) work? Example: Delete the session file, run something that leaves other session data around (or just leave it empty if you prefer), then try this: test1.php: http://localhost/test2.php";); exit; ?> test2.php: This will work, the second script will show only the single element "Test1" in $_SESSION. However if you replace: $_SESSION = array(); in test1.php with: unset($_SESSION); then test2.php will show whatever session data was present prior to invoking test1, and will not show the "Test1" array element in $_SESSION. In other words it not only retains the old values, but fails to save the new ones. -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using unset with $_SESSION
On 27 Jan 2004 Stuart wrote: > > I am trying to find a reliable method to clean out all session > > variables and start clean. > > http://php.net/session_destroy That destroys the file but (at least the docs say) does not clean out the global variables, and does not seem to work in my example. -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using unset with $_SESSION
On 27 Jan 2004 Stuart wrote: > In that case, try this... > > foreach (array_keys($_SESSION) as $key) > unset($_SESSION[$key]); Yes, I had tried that but forgot to mention it. It does work. However, I'm still mystified as to why unset($_SESSION) not only doesn't remove old data from the sesison file when the script exits, but prevents the new variable I create after that from being saved. Perhaps $_SESSION as created by PHP is special and is tied to the session storage, whereas if it is destroyed with unset and then recreated that link is lost. That would explain the behavior. -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Using unset with $_SESSION
> > Shouldn't unset($_SESSION) work? > > No. The following Caution appears in the manual (at > http://www.php.net/manual/en/ref.session.php#session.examples): > > Caution Do NOT unset the whole $_SESSION with unset($_SESSION) as > this will disable the registering of session variables through the > $_SESSION superglobal. Thanks -- I have to say I missed that one! Thanks for noting session_write_close() as well. I did try that, but it didn't seem to offer any advantages over letting the script write the data on exit. -- Tom Rawson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: fsockopen() errors.
On 8 Mar 2004 Phil Ewington - 43 Plc wrote:
> Can anyone tell me the best way to avoid errors using fsockopen(). I have
> tried wrapping the function call in a conditional statement, and have also
> tried calling the function and then testing the return.
Here's an approach I have used to avoid any error messages at all --
presumably you could also set a flag in the error handler to indicate
what happened, if you need that.
.
$olderr = error_reporting(0);
set_error_handler("ignoreerrhandler");
$fp = fsockopen(.)
restore_error_handler();
error_reporting($olderr);
if ($fp) {
[worked]
} else {
[failed]
}
.
function ignoreerrhandler($errno, $errstr, $errfile, $errline) {
return;
}
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] new session in new window
On 8 Mar 2004 Tim Traver wrote:
> I sent a new session ID with the link to the new window like this :
>
>
>
> but all it does is change the current session id to the new one, so if I go
> back to the main window, it carries the new session into it.
I think this is trickier than it sounds. Calling session_name with the
new name just prior to calling session_start should do it if you know
what name to set. But where are you going to get the name? If it is
hard-coded you are OK but if it is dynamic, as it has to be with user
logins, you need a place to store the session name -- and you can't use
sessions to do it! You end up having to pass at least something in the
URL, even if it is just a digit:
print("");
the URL would be something like:
http://www.mydomain.com/page.php?1
from which you do something like:
session_name("PHPSESSID" . $_SERVER["QUERY_STRING"]);
session_start();
(obviously some error-checking might be beneficial as well).
I don't think you can do what you want with sessions alone. HTTP is
"too stateless" for that!
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: using mail() for multiple email address...
On 8 Mar 2004 Adam Reiswig wrote: > Normally, the two emails would end up in the same pop account but don't > seem to be when I use the above script. If I send to one or the other > they receive appropriately, but if I send to both at the same time, I > only receive one email, not both. If anyone can help me as to why this > is and if there is a remedy, I'd sure like to know about it. Thanks a lot!! Is this on a Unix box? The same box where the domain is hosted? If so I think sendmail does that -- it notices the duplication, and only sends the message once. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Control Structure Syntax Question
On 9 Mar 2004 Richard Davey wrote: > $x ? xxx : xxx > > But it makes your code less readable IMHO and offers no tangible > benefit whatsoever. Ah, to each his/her own I guess ... I actually find: $value = ($condition ? $val1 : $val2); easier to read than: if ($condition) $value = $val1; else $value = $val2; On the other hand for this: $value = ($var1 && ($var2 == 4) && (($var3 == $var7) || ($var9 == "hello"))) ? htmlspecialchars(strstr($string1, $string2) . "test") : NULL; I would prefer to use: if ($var1 && ($var2 == 4) && (($var3 == $var7) || ($var9 == "hello"))) $value = htmlspecialchars(strstr($string1, $string2) . "test"); else $value = NULL; In other words ... IMO you can use the ?: operator to be concise (which increases readability) or to be cryptic (which reduces it). -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] strip down Warnings
On 10 Mar 2004 dmesg wrote:
> How can i tell fsockopen() to skip to echo this warnings?
Here's a repeat of something I just posted the other day on this ...
Here's an approach I have used to avoid any error messages at all --
presumably you could also set a flag in the error handler to indicate
what happened, if you need that. You need to both disable error
reporting and set a "do-nothing" error handler.
.
$olderr = error_reporting(0);
set_error_handler("ignoreerrhandler");
$fp = fsockopen(.)
restore_error_handler();
error_reporting($olderr);
if ($fp) {
[worked]
} else {
[failed]
}
.
function ignoreerrhandler($errno, $errstr, $errfile, $errline) {
return;
}
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Return value efficiency question
On 10 Mar 2004 Robert Cummings wrote: > Overhead is minimal since PHP doesn't actually copy the contents of the > container until an attempt to modify it is made. At which time the > contents are only actually copied if the internal reference count is > greater than 0. Generally this means it won't be copied since your > returning function will no longer be referencing it. This is not to be > confused with references as programmers work with them in scripts > themselves. Rob I have a related question, if you know ... what is the point at which passing objects by reference instead of by value provides a performance benefit? It sounds from the above like if you are not modifying the object in the called code then passing by value is always best because this is treated as a pass by reference unless and until there is a modification, so there is no performance cost. (I udnerstand that if modifying it then it must be passed by reference.) If that's right, then ... - does the same apply to arrays? - what happens if you pass an object by value and then call one of its methods which does not modify any data? Does the object get copied? Thanks for any insights ... -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How to make sure a redirect works
On 10 Mar 2004 Henry Grech-Cini wrote:
> My question is are there problems with:
>
> header("Location: ".$url[$index]);
> ?>
As long as no other headers have been sent that should work fine.
Location: is the standard method for redirection -- I'm not aware of
any circumstances in which it won't work. Perhaps others are.
If you output a location header then I don't know what the browser will
do with text sent after that. Hopefully nothing!
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Unique ID system - need help/ideas
On 10 Mar 2004 J J wrote:
> My problem is how do I recreate this in PHP to make
> sure any newly added records follow this same unique
> ID?
I haven't played much with these functions but I think for MySQL you'd
want something like this, for the state "XX" (excuse the wrapped
lines):
if ($result =
mysql_query("select max(id) from table where left(id, 2) = 'XX'")) {
$row = mysql_fetch_row($result);
$newid = strpad($row[0] + 1, 5, "0", STR_PAD_LEFT);
mysql_query("insert into table set id = 'XX'" . $newid);
$newrecnum = mysql_insert_id();
}
That is crude and uuntested, needs some error checking and most likely
table locking, but it's one possibility for a base.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Regexp Oddity
I must be missing something obvious ... I am trying to use
backreferences in a PCRE regexp to check for a repeated character, but
they don't seem to work. I've used regexps often before, but never
needed backreferences.
For example this:
print "Matches: " . preg_match("/(a)\1/", "aa");
prints:
Matches: 0
It should be 1.
In addition the basic examples in the manual fail. The manual says:
For example, ((?i)rah)\s+\1 matches "rah rah" and "RAH RAH", but
not "RAH rah", even though the original capturing subpattern is
matched caselessly.
I tested this with:
print "Matches: " . preg_match("/((?i)rah)\s+\1/", "RAH RAH") . "\n";
print "Matches: " . preg_match("/((?i)rah)\s+\1/", "rah rah") .
"\n";
Both show 0.
For this test I'm running PHP 4.3.1 on Windows 2000.
What am I missing?
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Regexp Oddity
On 11 Mar 2004 Raditha Dissanayake wrote:
> print "Matches: " . preg_match('/((?i)rah)\s+\1/', "RAH RAH") . "\n";
> print "Matches: " . preg_match('/((?i)rah)\s+\1/', "rah rah") .
>
>
> is what you should use.
Oh. Of course -- I knew it was obvious! This also works:
print "Matches: " . preg_match("/(a)\\1/", "aa") . "\n";
print "Matches: " . preg_match("/((?i)rah)\\s+\\1/", "RAH RAH") . "\n";
print "Matches: " . preg_match("/((?i)rah)\\s+\\1/", "rah rah") . "\n";
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Get "nice" variables from POST
On 11 Mar 2004 Mike Mapsnac wrote: > I'm looking for "nice" way to get variables from POST? Well you can do it easily with extract: extract($_POST); This has the same security risks as turning register_globals on, it allows hackers to set any variable they wish. A better method might be: extract($_POST, EXTR_PREFIX_ALL, "p"); which results in $p_username, $p_password, etc. This still allows insertion of variables but they will all be prefixed with "p_" which hopefully you aren't using for anything else. If you want to restrict it to only the specific values you care about use the approach someone else suggested with the $fields array. THat seems the safest to me. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Get "nice" variables from POST
On 11 Mar 2004 Teren wrote: > If you have register_globals on in your php.ini file, you don't need to do > that. You just automatically have access to all of those variables like > $username and $password etc. Whatever the name is on the field is what the > string will be called and the action script can access those immediately by > $+the_field_name. Yes but register_globals carries substantial security risks since a hacker can then set any script variable they wish merely by POSTing it back in response to your form. For details see http://www.php.net/manual/en/security.registerglobals.php. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Get "nice" variables from POST
On 11 Mar 2004 Rob Adams wrote: > Along the same lines, I've found this helpful when inserting into mysql. > > foreach($_POST as $key => $val) > $$key = mysql_escape_string($val); I just wrote a cleanup routine which applies a number of transformations -- it's called at the start of every page (if there's no post data, it won't do anything). Here's roughly what it does (the actual code has more nuances): foreach(array_keys($_POST) as $keyname) $_POST[$keyname] = stripslashes(strip_tags(substr(trim($_POST[$keyname]), 0, 255; This eliminates HTML and PHP tags, and escape sequences (noe of which I need to accept), and avoids problems if someone tries to post an outrageously long . Then I apply mysql_real_escape_string after that for stuff going into the database. If anyone sees problems with this, or a better way to do it, I'm open to feedback! -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Get "nice" variables from POST
On 11 Mar 2004 Chris Shiflett wrote: > The risk is no greater than what the original poster wants to do anyway: > > $foo = $_POST['foo']; > > Whether $foo is created by register_globals being enabled or by the > previous code, there is no difference in risk. The data should still be > considered tainted until it has been properly validated, and disabling > register_globals does not excuse you from performing this step. I totally agree -- I certainly didn't mean to suggest otherwise. The original question was about how to get a specific set of "about 10" variables out of the _POST array so he wasn't always having to use array references. One of the responses suggested using register_globals and that's what I was responding to. It seems to me that for security one wants both things -- first, to move only what you need from _POST into the global symbol table, and second, validate it thoroughly. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Get "nice" variables from POST
On 12 Mar 2004 Mike Mapsnac wrote:
> I try to use quotes in the query and this doesn't work.
>$query = "SELECT * FROM user WHERE user_id = '$_POST['user_id']}'";
> But you use brackets and it works.. Why do you use brackets ?
> $query = "SELECT * FROM user WHERE user_id = ${_POST['user_id']}";
See http://us3.php.net/manual/en/language.types.string.php, scroll to
the section called "Complex (curly) syntax".
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Static vs. Dynamic Build of PHP4
I am running on one Linux server which has PHP built statically; the CLI and Apache modules are both over 5.5MB. On another where it is built dynamically they are closer to 1.2MB. Is there any data on the performance tradeoffs of static vs. dynamic builds? I understand the factors (static eliminates the overhead to load needed libraries, dynamic reduces memory footprint) but I wonder if there is any real-world data on when one is better than the other. We are using PHP primarily as an Apache module, not CGI or CLI. Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Get "nice" variables from POST
On 12 Mar 2004 Richard Davey wrote: > Indeed.. roll-on input filters in PHP5 :) Hmmm, can't find the docs on those online. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] XSS Vulnerabilities and strip_tags
Is the general wisdom that using strip_tags on input is sufficient to protect against XSS vulnerabilities from that input? I have been doing some reading on it but haven't found anything that suggests a vulnerability that removing the tags in this way would not cure. Are there multi-level encodings that can get past strip_tags? I probably should also be doing a urldecode before strip_tags to get around any hex encodings, or does strip_tags handle that? Thanks for any info, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] STrange Problem
On 12 Mar 2004 Richard Davey wrote: > P> 1044: Access denied for user: '@localhost' to database 'mydatabase' > > You said that you use "apache" as the username for MySQL - is this > something you've configured yourself? It appears he is actually using a blank username as there is noting before the '@' in the error message. > If not, it should be "root" and the password should be blank unless > you have also set that? Configuring a MySQL database with a blank root password sounds like a potential security risk to me ... why not just create a MySQL user/PW for the specific PHP application and connect that way. Then you can grant that user just the privileges they need to deal with the actions the web page can take (SELECT, UPDATE, INSERT, and DELETE might be enough, or even too much). -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP] STrange Problem
On 12 Mar 2004 Richard Davey wrote: > It is, but if he hasn't modified it otherwise, that's what it'll be. > Also for local development purposes, there is no harm in it. Agreed, as long as he's not connected so someone can try to connect to the MySQL port. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] STrange Problem
Is it possible that either $connect_id is not defined at the point where you use it in the mysql_select_db call (e.g. it's global, the call is in a function, and you forgot to use a global declaration), and/or the previosuly opened connection has been closed? What do you get if you do a var_dump($connect_id) right before the mysql_select_db call? -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] New Problem with Arrays won't show the first record of a query.
On 12 Mar 2004 Elliot J. Balanza wrote:
> .
> $row_prefs = mysql_fetch_assoc($prefs);
> .
> while ($row_prefs = mysql_fetch_assoc($prefs)) {
> .
> and it works fine EXCEPT it wont show the first record of the query... any
> ideas why?
Yes ... see the two lines quoted above. Each time you call
mysql_fetch_assoc you get another record. The first one loads the
first record, the second loads all the others. Delete the first call
and it should do what you want.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP and Apache 2
> So the current situation is that Apache2-prefork+PHP is a decent solution > but it hasn't been tested a whole lot. I am currently moving my app to an Apache 2 server. I did not build the server (not my area of expertise) and don't know how how it was built, but I can talk to the folks who did it and find out. It was their choice to go to Apache 2, but I still have time to get them to go back if need be. I'd like to understand the recommendations more clearly. Are there configurations of Apache 2 that are OK with PHP? The above suggests prefork hasn't been tested but the remainder of your message suggests multithreading (which is different from prefork as I read the Apache docs -- right?) is even more problematic. It sounds like this is what's behind the recommendation at http://us2.php.net/install.apache2 which says "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows." But the same page says "The following versions of PHP are known to work with the most recent version of Apache 2.0:", so I'm not quite clear on what's being recommended. FWIW httpd-l on the new server shows: Compiled in modules: core.c mod_access.c mod_auth.c mod_include.c mod_log_config.c mod_env.c mod_setenvif.c mod_ssl.c prefork.c http_core.c mod_mime.c mod_status.c mod_autoindex.c mod_asis.c mod_suexec.c mod_cgi.c mod_negotiation.c mod_dir.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_so.c Thanks for any comments. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP and Apache 2
On 13 Mar 2004 Rasmus Lerdorf wrote: > I think that is pretty clear. It says that it works but we do not > consider it production quality. OK, thanks. That is what I thought it meant but I wanted to be sure. > As for whether your particular install will work? I have no idea. Maybe, > maybe not. And if weird things happen chances are we won't be able to > help you fix it. That's the essence of our reccomendation to stick with > the Apache1 codebase we know well until such a time that Apache2 actually > delivers substantial enough features to warrant the effort it is going to > take to hammer it into a production-quality environment. Thanks. I wasn't asking if it would work, just what the recommendations were. That's very clear. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Regex help
On 15 Mar 2004 Eric Gorr wrote:
> >which will have a value like:98797-234234--2c-something-2c
> >
> >How do I take out the part which will always start with "--2c" and will
> >always end with "-2c"
>
> I'd be interested in the answer to this question as well.
> Seems like it should be easy.
It is easy. I agree with whoever said string functions were a better
solution, regexp is overkill unless there is more variaiton in the data
than what was presented. That said, here are some possibilities; all
but the first assume that the "--" is always there:
- If the lengths are constant just use substr to pull out the
first 11 characters.
- Find the "--" with strpos and then use that in a substr call to
take just the part to the left.
- Use explode to separate the string at the "--" or "--2c".
- For two numeric strings separated by a dash use a regexp
approach something like this:
if (preg_match("/^(\d*-\d*)--2c/", $string, $matches))
$left_part = $matches[1];
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Sessions - One Server, Many Terminals
On 16 Mar 2004 [EMAIL PROTECTED] wrote: > Sessions have to do with requests being sent by browsers to the web server. Each > time > you close all the windows of your browser on your computer and start the browser > again, a new session is started. I suspect that since all your users are essentially > using > the same web browser (since their monitors and keyboards are not really separate > computers, but peripherals on the same machine), a browser window open on one > terminal is keeping alive a session started by another user on another terminal when > she or he first started the browser. I have had questions about this for a while. What is it about closing and reopening the browser that PHP "notices" and that invalidates the old session? Also a comment ... I think with the right combination of session_id() and session_name() calls you should be able to run multiple sessions on the same browser at the same time. I have never tried it but I did have a client with an interest in it and I looked enough to say "well, I think this is feasible -- we'd have to try it to be sure". -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] refresh page
On 17 Mar 2004 Mike Mapsnac wrote:
> I need to refresh page every 2 minutes. How that's can be done in
> PHP?
You can do it with a header. I think something this simple will work:
header("Refresh: 120");
or in the area:
print "\n";
If you want to refresh to an explicit URL:
header("Refresh: 120; URL=http://...";);
print "http://...\";>\n";
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP list in Spanish
On 16 Mar 2004 Freddy Rodriguez wrote: > Hay una lista en español para php? (Is there a list in Spanish for PHP?) Si hay. Mira http://www.php.net/mailing-lists.php y http://news.php.net/group.php?group=php.general.es. (Yes there is. See the two URLs above.) -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP] Re: PHP Sessions - One Server, Many Terminals
On 17 Mar 2004 Tom Rogers wrote: > The default lifetime for session cookies is until the browser is > closed. Of course. > You can run multiple sessions as long as they are to different > domains I think. I am pretty sure PHP can only handle 1 session per > client but you could always roll your own on top of that with > cookies/and or ID's Hmmm, I would contend that PHP, particularly running inside stateless HTTP, doesn't know one client from another except by the code you write that makes it recognize them, or that uses defaults to do so. If you only look at the default $_COOKIE["PHPSESSID"] to figure out what session you are handling then you get one per client, but if you had a way to set multiple cookies (easy) and to know which one you cared about on the next page load (harder, but at least it seems doable in the URL) then you can run multiple sessions. Maybe that's what you meant by "roll your own" ... -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] refresh page
On 16 Mar 2004 Jeff Oien wrote: > You have to basically go back and forth between two pages. The site you mentioned does, but it is easy to refresh to the same page -- just use your own URL. An empty URL also works -- I tried it in IE 6 and Mozilla 1.5; don't know if it works with other browsers. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP On Solaris 9 - MySQL Problem
You might try an fsockopen() to port 3306 on the dbserver and see if it works. If not, you get a reasonably descriptive error. I just tried a couple of known servers and bogus addresses with this code: A server listening on that port produces: resource(4) of type (stream) string(0) "" NULL One that is not produces: Warning: fsockopen() [http://www.php.net/function.fsockopen]: unable to connect to 192.168.1.1:3306 in d:\TEST2.PHP on line 2 bool(false) int(10060) string(185) "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond." I get the same response whether I try it from CLI or within Apache. I did the test on Windows but the same would work and might tell you something useful if run from the server. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Global variables in a class? Nested classes VS inheritance...
On 17 Mar 2004 Brent Westmoreland wrote: > I too have questions on how to handle this situation, any help would be > greatly appreciated. [Situation was how to use a single database connection inside a class nested within another class etc.] If you have a single DB connection open for the entire script why not use a global variable? There are good reasons for not overusing global variables but sometimes there are good reasons to use them too. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] auto closing session?
On 18 Mar 2004 Louie Miranda wrote: > On my website i massively use session. And often times the webserver is > lacking resources to process more queries, and thats where all my > applications are failing. > > I issue a destroy session at the end of my transaction, but some users dont > end their transaction and thats the big problem for me. How can i solve that > problem? I believe you can adjust session.gc_maxlifetime to do that but I also don't think it is likely to be the problem. An inactive session takes up only disk space, it does not use processing resources. If you have httpd or other processes that are not terminating after your script exits that is a different issue. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP] ereg_replace help
On 18 Mar 2004 Richard Davey wrote: > Nope, because in the only reference book I had to hand it said the ^ > matched the start of a string so it didn't occur to me to try it. > > Thanks to John I now know when used in a block it's no longer limited > to the start of the string. The code you posted above works, thanks. The '^' has a totally different meaning inside a character class than its meaning outside the class. It's not a amtter of it being "limited" so much as just "different" (actually I guess "overloaded" is the real term). -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP On Solaris 9 - MySQL Problem
On 18 Mar 2004 Cameron B. Prince wrote: > I'm sure this is good to know because it proves at least part of PHP can > reach the other machine... Which hopefully rules out a TCP/IP problem. I'm > going to enable debugging on the MySQL server and see if that tells me > anything. Ah, that's good. Then it is just a problem of MySQL. Have you tried accessing a remote machine running MySQL 3.2x instead of 4.0? That seems like an obvious potential culprit. Note that the standard MySQL extension carries this note: This MySQL extension will not work with MySQL versions greater than 4.1.0. For that, use MySQLi. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Get form name after submission
On 18 Mar 2004 Richard Davey wrote: > Good question, but the answer is no - I don't believe you can. You > could try passing the form name as a hidden form value? Or name your > submit button accordingly? I have done this with the Submit button but I find that the results vary. If you click Submit it always works, but for example, with the versions I have here, the Submit button value is not posted if you press Enter from within a form field in IE, whereas it is in Mozilla. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP On Solaris 9 - MySQL Problem
On 18 Mar 2004 Cameron B. Prince wrote: > I just finished doing that on a third machine that didn't have a previous > MySQL installation. I installed the same version that the webserver has. I > had the same results. I'm losing track here -- are you saying you can't connect to another machine running MySQL 3.x from PHP but you can from the mysql command line client? So this behavior is verified against both a MySQL 3.x and 4.x server? If so I agree, getting the router / firewall out of your way is a good idea, though why it would matter if you can open a socket connection, I don't know. > > Note that the standard MySQL extension carries this note: > > > > This MySQL extension will not work with MySQL versions greater > > than 4.1.0. For that, use MySQLi. > > > > Not sure what MySQLi is, but I had thought since the 4.x mysql client worked > from the console, that there was no version problem because it would be > using the same client libraries that PHP is using. Is that not the case? I'm not at all clear on that. For one thing it depends if the various pieces were built dynamic or static. I would not make this assumption. I thought you said the web server had MySQL 3.23 on it -- do you also have a MySQL 4 client there? -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP On Solaris 9 - MySQL Problem
On 18 Mar 2004 Cameron B. Prince wrote: > I'm saying I can't connect to another machine running 3.x or 4.x from PHP, > but I can connect to either via the v4.x mysql command line client that's > installed on the webserver with PHP. OK, I get it. It certainly sounds like it could be a problem with the client libraries. Did you build PHP on the web server or was it built for you? Have you tried connecting from a different machine using PHP (to test if it is just the build of PHP on that one machine that's the problem)? -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert Date Format?
On 20 Mar 2004 Jeff Oien wrote: > How do I convert this > 9/8/2001 > (which is Month/Day/Year) > to this > 20010908 > (YearMonthDay - with leading zeros) How about: -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Scheduling PHP on Windows
On 20 Mar 2004 Ben Ramsey wrote: > I know how to run a PHP script as a cron job on a *nix machine. So, > does anyone know how to use the Task Scheduler on Windows to do the > same? Or is it even possible? The fundamental idea is simple -- work out a command line from a regular command prompt that does what you want. Then set it up under Control Panel / Scheduled Tasks. You will have to specifically invoke cmd.exe if you want to redirect the output, for example here's a command line I just tried that worked properly: m:\winnt\system32\cmd.exe /c h:\php\cli\php.exe test4.php >> c:\x.txt -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On 21 Mar 2004 Chris Shiflett wrote: > SQL injection vulnerabilities exist when you use data that the user gave > you to create your SQL statement. So, anytime that this happens, simply > make absolutely sure that the data you are using from the user fits a very > specific format that you are expecting. > To be clear: make sure the data that the user submitted only contains the > characters you think are valid (don't bother trying to guess malicious > characters - you're sure to miss one) and is a valid length. Once you've > done this, and your design helps you to make sure that this step can't be > bypassed by the user, you're protected against SQL injection. Recently I've been in the middle of trying to build defenses against SQL injection on a site I'm working on (proactively, we haven't had a problem). While this principle seems exactly right, I find it's not as easy to implement as it sounds, and I'd argue that the results aren't as absolute as you suggest, though you certainly have more experience with it than I do so perhaps I'm missing something. Here's how I'm looking at it. Pretty much any useful site tied to a database will use user data in SQL statements, either in WHERE clauses or SET clauses or both. This means all input must be checked for maliciousness, and the primary kinds of malicious input seem to be SQL injection, or on another front HTML injection / XSS. The problem is that there are some well-defined attacks with protections against them that can be logically defended. But there is no list of all possible attacks, so I'm not sure it's really possible to say "you're protected against SQL injection" at some point. Do you feel differently? If so I'd be interested to hear why. I agree with you that checking for valid characters is safer than checking for malicious characters, but even the former is not absolute. Also it is not possible to make the set of characters with syntactic significance have no overlap with the set of valid input characters -- a single quote used as an apostrophe is the obvious example, so checking for valid characters may still leave characters in the data that could also be part of an attack. As for specifics, at the moment I am simply forcing every element of _POST to be truncated to a known maximum length, then run through strip_tags, stripslashes, and htmlspecialchars (in that order) before I use it. Then every input form element is validated against an appropriate regexp depending on the type of input expected. I also use mysql_real_escape_string on all strings prior to writing them to the database, and I use single quotes around all integer values. If you're game, I'm curious if you see any flaws in this approach. I am still contemplating whether there is any value to running input through htmlspecialchars, or whether I should instead simply be using htmlentities on output. I also haven't looked at what this does to nested attacks of various kinds and whether there is a way to use multiple iterations or escapes in the input data to bypass the filtering (pointers to articles which discuss this would be welcome). Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On 21 Mar 2004 Chris Shiflett wrote: > I would never argue that something is an absolute defense, but I would > characterize my recommendation as a best practice. Fair enough. > > I agree with you that checking for valid characters is safer than > > checking for malicious characters, but even the former is not absolute. > > Not absolute in what sense? Making sure something is valid is pretty > absolute; Yes, agreed. It just that validation against input criteria doesn't guarantee that it's not an attack. > the only possible flaws are flaws in "making sure something is > valid." For example, I feel confident that no one can show me a string > that I would consider a valid first name that is also an SQL injection > attack. I'm sure that's correct. However I'm not sure the algorithm to definitively decide which is which is so obvious. > http://phundamentals.nyphp.org/PH_storingretrieving.php FYI, this site seems to be down. I've tried it several times over the last few days and it always times out. > This doesn't work for everyone. I can think of several examples where > users would be submitting HTML and/or PHP code. I wouldn't want to delete > some of their data. Of course. I was only referring to my specific case, where that's not an issue. > I applaud your efforts in data filtering, because almost all PHP > vulnerabilities that I read about are a result of the author completely > failing to perform any data filtering at all (which is inexcusable). > However, might I suggest that you take a slightly different approach. > Verify that the data is exactly what you expect it to be, and then escape > and/or encode it when necessary. Just to clarify ... are you saying that you feel it's better to specifically validate and encode each field according to its own requirements rather than use a global algorithm? I can understand that ... right now I do both, global checks first followed by field-specific validation and encoding / escaping. > For unvalidated data, do nothing with it until you have validated it with > your data filtering logic. A good software architecture should make it > easy for the developer to keep up with this (naming conventions are also > very helpful for this). Good point on the naming conventions. I tend to keep the raw data in _POST and the validated data inside an array of "control" objects within my data entry "form" object, so the differentiation is structural rather than by name. > This actually sounds like a strong approach to me. I assume that you > surround all data in an SQL statement with single quotes (not just integer > values). In fact, this is almost exactly what I am suggesting. I do not > think you have an SQL injection vulnerability, unless what your code does > strays from this description somehow. Yes, I use single quotes on everything. I was doing it only for strings and dates, but after reading some of the MySQL security info I added single quotes to the numeric values as well. > Also, if your applications never allow the user to submit HTML or PHP, > stripping tags is fine. But, you might be interested in letting your > regular expression catch this, so that you can log attacks. Attackers > certainly profile your applications - why not profile their attacks? It > can potentially help us all. Good point ... but then I am vulnerable to errors in my own algorithm, I figured the folks writing PHP were likely to have more experience with it than I did. However it would be fairly easy to check if strip_tags did anything by comparing string lengths, and log the change if there was one. > > I also haven't looked at what this does to nested attacks of various > > kinds and whether there is a way to use multiple iterations or escapes > > in the input data to bypass the filtering (pointers to articles which > > discuss this would be welcome). > > The point of escaping or encoding would be lost if it didn't work for all > possible data. I know of no articles for this, nor can I think of anyone > who would bother writing one. :-) That's true, but as there is no mention in the documentation, I have no idea whether functions like mysql_escape_string properly handle things like strings which have already been escaped, whether strip_tags will take care of something like http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On 23 Mar 2004 Michael Rasmussen wrote: > The idea is exactly not to do any queries dynamically generated based on > user input! In the rare cases where this is needed you should not > allow any unparsed input. There are some applications for which queries based on typed user input are rare. But there are others for which those queries are the basis of the whole application! Almost any kind of site where users are creating accounts and other data records (or their equivalents) will be like this, and that's a very common kind of web application. I agree that in these cases the input should be validated, I think that was the original topic of the thread. But I don't think you can call this "rare" as a general rule. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] RE:[PHP] sessions...how to use not clear?
On 22 Mar 2004 Andy B wrote: > so the theory is: if i require that the session be named after the persons > login name there is probably 1 out of 2 million chances that it will mess up > the names and get confused (specially if there are only a few users > allowed)... If the login name is unique and you don't allow multiple simultaneous logins then the chanve of a mixup is exactly zero. If you are talking about session IDs, I believe they are 128 bits which translates to a chance of duplication of 1 in 340,282,366,920,938,463,463,374,607,431,768,211,456 [the result from bcpow(2, 128, 0)]. Should be good enough :-). -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: parsing xml the right way
On 2 Apr 2004 Aidan Lister wrote: > Wait until you have installed PHP5, then use the simplexml library. I will shortly have the same questions about ways to parse XML, and I can't use PHP 5 -- it's a production environment and the PTB are not going to move to something that is that recently released. ANy other suggestions? -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session hell: register_globals off
On 4 Apr 2004 Randall Perry wrote: > Solved my main problem. I was assuming that variables registered with > $_SESSION were passed by reference. Apparently they're passed by value. *Passing* by value or by reference has to do with function parameters, not array values. However you can assign one variable as a reference to another, see http://www.php.net/manual/en/language.references.php. When you enter a line of code like: $_SESSION['order'] = $order; you are doing a regular assignment. To use a reference instead, use: $_SESSION['order'] =& $order; The data will be passed this way to the next session. For example, try this (substitute your server name in the header() call): test1.php: http://localhost/olm/test2.php";); ?> test2.php: The output on the second page will be something like this (I'm using xdebug so this is not raw var_dump() output): array 'Test1' => 'this is test1' -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
