[PHP] Determining Built Configuration
I need to rebuild PHP on a Linux box (RHEL). It has been built there before but I cannot locate the proper command line for configure -- config.status is no longer accurate as configure was run with no arguments. Is the old configure command line saved in a log somewhere? If not is there a simple way to sort out the options that were used to build the current version? This is PHP 4.3.4 running as part of an Apache 1.3.x static build and also a CLI version. Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Determining Built Configuration
On 8 Nov 2005 Minuk Choi wrote: can you get the output from phpinfo()? Thanks. I've used phpinfo() many times but never looked at that bit of the output. It's exactly what I needed. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Determining Built Configuration
On 8 Nov 2005 Richard Lynch wrote: You should run it from the browser, and from the CLI separately, as they could be different builds. I had wondered about that but they are the same build. I was planning to double-check anyway. There is also config.nice if it was installed from source. Not if configure was run again since -- it overwrites it as far as I can see. Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Build Problem??
Building PHP 4.3.4 with Apache 1.3, SAPI and CLI versions (no CGI) ... Now that I found the config command used for the last build, I rebuilt PHP (config, make, make install) with one change -- at the end of the config line I added --enable-dbase. If I look at the phpinfo() output now, in both CLI and SAPI versions, I still see the *old* build date, and the *old* config command -- but I also see dbase listed as an additional module, and the dbase functions now appear to work. What gives here? Is there something special about dbase? Perhaps -- enable-dbase affects link step and not compile, but the config line and build date are captured only in a full compile? -- 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 : span class=author
authorend : /span
so, the translate function looks 'authorstart' up and returns 'span
class=author'
or if you had specified 'wml' as the outputtype, the file could like like:
authorstart : b
authorend : /b
and the function would return 'b'
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] 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] 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] 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] 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] 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:
html
head
title Web-safe color 'opposites'
/head
body
?php
# Display color opposites for web colors
$weblist = array('00', '33', '66', '99', 'CC', 'FF');
print(table cols=\4\ cellspacing=\5\ cellpadding=\0\);
print(tr\n);
print(th align=\right\Color/td\n);
print(th width=\100\ align=\center\Color swatch/td\n);
print(th width=\100\ align=\center\'Opposite' swatch/td\n);
print(th align=\left\'Opposite' color/td\n);
print(/tr\n);
foreach ($weblist as $red) {
foreach ($weblist as $green) {
foreach ($weblist as $blue) {
$hexcolor = $red . $green . $blue;
$hexoppcolor = sprintf(%06X,
(hexdec($hexcolor) ^ 0xFF));
print(tr\n);
print(td align=\right\#$hexcolor/td\n);
print(td width=\100\ height=\20\
bgcolor=\#$hexcolor\nbsp;/td\n);
print(td width=\100\ height=\20\
bgcolor=\#$hexoppcolor\nbsp;/td\n);
print(td
align=\left\#$hexoppcolor/td\n);
print(/tr\n);
}
}
}
print(/table\n);
?
/body
/html
--
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 br';
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] 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] 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] 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] 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] 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] 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] 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 input type='text' name='name'/ To: input type='password' name='name' 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] 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 pre then the tabs and newlines should work. For the original poster -- in other words, near the start: $row = preFilesystem\t . Size\n; and near the end: $row .= /pre\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] 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] 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] 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
[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] 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
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
[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] 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
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] Clear POST variables on page refresh
On 3 Feb 2005 Richard Lynch wrote: If it was only two pages, and there was only one header() re-direct, fine. But what ends up happening is you get in the habit of doing this all over the place, and you have a mess of spaghetti logic spread over a hundred files. That is a problem with coding practices, not with the method used. All you need to do is write a redirect() function used in all pages and call it instead of header(). Then you have one point to change if you need to make a change as you describe. The fact that someone did not do this does not mean the underlying method is a poor idea. It just means they didn't anticipate the need for application-specific code as part of the redirect operation. Put another way, it's a common error to fail to build an abstraction layer for this type of low-level operation, but it doesn't mean using the low-level operation is a mistake. The error, if there is one (and I'd say there is in the scenario you describe) is in not noticing the need for an abstraction layer. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a mysql_connect() bug?
On 29 Jan 2005 tom soyer wrote:
I tried mysql_connect() function, and it won't reture FALSE if
connection failed. Instead, the script times out after 30 seconds and
displays an Fatal error message Maximum execution time of 30 seconds
exceeded.
I think the issue here is if the server does not respond it hits the
execution time limit before the function returns.
I use code like this:
$olderr = error_reporting(0);
set_error_handler('ignoreerrhandler');
$dbHandle = mysql_connect($dbHost, $dbUser, $pw);
restore_error_handler();
error_reporting($olderr);
.
function ignoreerrhandler($errno, $errstr, $errfile, $errline) {
return;
}
You can also control the connection timeout with the
mysql.connect_timeout setting in php.ini.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Regex help
On 28 Jan 2005 [EMAIL PROTECTED] wrote: I need a validation regex that will pass a string. The string can be no longer than some maximum length, and it can contain any characters except two consecutive ampersands () anywhere in the string. This is an example of something that is easier to do (and probably faster) without using a regexp: if ((strlen($str) = $maxlen) (strstr($str, '') === FALSE)) str is valid else str is not valid -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Regex help
On 28 Jan 2005 [EMAIL PROTECTED] wrote: Thanks, Tom. I agree, but not an option at this time - other parts of the design require this to be a regex. It is pretty easy to do with two regexps, one to check the length and another to see if there is a double . Would that work? I don't know off hand how to do it with a single regexp. If the design requires that every possible condition be checked with a single regexp then I would say, no offense intended, that the design is faulty. Regexps are good tools but are not universal for all possible conditions one might want to test. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Avoiding NOTICEs on Array References
On 26 Jan 2005 Jason Barnett wrote:
if (isset($_POST['checkboxfieldname'])) {
/** do stuff */
}
Sorry, I should have mentioned that I knew about using isset -- it
works OK for the checkbox example, though I'm not clear if this
behavior is specified and therefore will not change -- i.e. can one
rely on the fact that the checkbox field name is missing entirely from
_POST if the box is not checked? Or are there cases where it could be
present but with an empty or NULL value?
If one must check the value and not just the existence of the checkbox
entry, or for other uses, e.g. where a flag may or may not be present,
one is saddled with clumsy constructs like:
if (($isset($array['index']) ($array['index'] == 1)) ...
I would prefer that the second expression return FALSE, or that
$array['index'] where the index is not present simply return NULL -- or
probably better, an option to avoid E_NOTICE level errors for such
cases.
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding NOTICEs on Array References
On 26 Jan 2005 Jennifer Goodie wrote: if (isset($fields['flags']['someflag']) $fields['flags']['someflag']) if (isset($_POST['checkboxfieldname']) $_POST['checkboxfieldname']) The short-circuits, so the second part of the conditional only gets evaluated if the first part is true. I know I can use isset, it just adds a bunch of extra code. I like to find minimal solutions to these things if possible as they are easier to read, and faster to execute. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Allowing Users to Edit HTML
On 24 Jan 2005 Richard Lynch wrote: Assuming you are authenticating them correctly so that a Bad Guy can't change the HTML out from under them, it seems reasonable to me -- Not much point to cross-site vandalism on one's own site, eh? Exactly, that was my thought as well ... -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Avoiding NOTICEs with list()
On 24 Jan 2005 James Kaufman wrote: I just tried it with php 4.3.8 and it did not throw a NOTICE with @list. I suppose you could try @explode as well as @list. Thanks. I was sure I had tried it with that but I will go back and check. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Avoiding NOTICEs with list()
This construct:
list($v1, $v2, $v3) = explode($sep, $string, 3);
will generate NOTICE level errors if there are not enough parts of the
string to fill all the variables in the list. What I really want is
for list() to set the variables that have a corresponding array
element, and then either don't change the others, or set them to NULL --
I could live with either approach.
Anyone see a way to get rid of these errors short of this approach:
$parts = explode($sep, $string, 3);
switch(count($parts)) {
case 3:
$v3 = $parts[2];
case 2:
$v2 = $parts[1];
case 1:
$v1 = $parts[0];
}
I did try @list(... and it made no difference.
Thanks,
--
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Allowing Users to Edit HTML
I am a consultant developing a PHP-based site (fully operational now, we're adding some new features). One thing I need to do is allow resellers of my client's services to edit HTML which will then be used on the web pages their customers see. In other words they get to customize the appearance of their portion of the site. Most of the data entry involved is stuff where they plug in some data and I create the HTML with it -- stuff like colors and titles. But in some cases I need to allow them to enter HTML code themselves. I am currently running the code through htmlentities() before displaying it in the form field for them to edit. The _POST data is run through trim(), then substr() to limit the length, then html_entity_decode(), before doing any further processing. We also use strip_tags() on all fields in _POST except the HTML data, and everything that goes into the database is run through mysql_real_escape_string(). Do these methods seem reasonably secure? Am I missing something? The risk is minimized by the fact that the HTML the user enters is displayed to their own customers, whom they presumably don't want to attack (and if they did they could just do it on their own web site). But I still want to avoid as many opportunities as possible for either inadvertent or deliberate errors to cause trouble. Thanks for any comments, -- 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:
?php
$end_date = 2004-04-10;
for ($i = 1; $i = 30; $i++) {
$check_date = mktime(0, 0, 0, substr($end_date, 5, 2),
substr($end_date, 8, 2) - $i, substr($end_date, 0, 4), -1);
$strdate = date(m-d-Y, $check_date);
print($check_date = $strdate\n);
}
?
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] PHP 4.3.4, Apache w/ mod_ssl Compile Help
Hi Folks ... A small problem here ... I just rebuilt Apache 1.3.29 with mod_ssl. When doing apachectl startssl I get: [Mon Apr 5 12:19:53 2004] [warn] Loaded DSO libexec/libphp4.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI) I read through many postings on this topic and the opinion seemed to be that rebuilding PHP with CFLAGS=-DEAPI would fix this, as would simply rebuilding it after Apache as the rebuild should pick up the new APXS file which would define this symbol. After rebuilding Apache with modssl as follows: ./configure --enable-module=so --enable-module=ssl make make install I ran from the PHP directory: make clean make make install If I then do an apachectl stop followed by apachectl startssl I get the error again. I have verified that the new libphp4.so is installed in /usr/local/apache/libexec, and that /usr/local/apache/bin contains the latest apxs file, and that the PHP configuration line points to that file. I have tried the PHP rebuild both before and after setting CFLAGS=- DEAPI in my local shell environment (with export). The results are the same -- the error shown above. What am I missing? FYI, the PHP config as shown in config.status is: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386- redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/us r/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/u sr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sh aredstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix =/usr --with-config-file-path=/etc --enable-inline-optimization --with-exec-dir= /usr/bin --with-pear=/usr/share/pear --with-mysql=shared,/usr --with-apxs=/usr/local/apache/bin/apxs --with-openssl --with-mcrypt --with-curl Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP 4.3.4, Apache w/ mod_ssl Compile Help
On 5 Apr 2004 [EMAIL PROTECTED] wrote: When doing apachectl startssl I get: [Mon Apr 5 12:19:53 2004] [warn] Loaded DSO libexec/libphp4.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI) Sorry, I just realized there is a separate php-install list. I will repost this there. -- 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: ?php session_start(); $test1 = ; $_SESSION[Test1] = $test1; $test1 = this is test1; header(Location: http://localhost/olm/test2.php;); ? test2.php: ?php session_start(); var_dump($_SESSION); ? 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
Re: [PHP] $HTTP_SESSION_VARS still holds original values even after unset?
On 4 Apr 2004 Andy B wrote: how would you empty all the contents of $HTTP_SESSION_VARS when you dont need them anymore but still keep the current session running? See http://www.php.net/manual/en/function.session-unset.php. That is exactly what it does. That page also explains why unset() is not the right way to go. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: $HTTP_SESSION_VARS still holds original values even after unset?
On 4 Apr 2004 Andy B wrote: the next time i hit the add guestbook listing from the main screen, fill out the form with different values and submit it all the $HTTP_SESSION_VARS have the same values as the last add sequence... There are two problems there. First, your session data is not getting cleared. Second, it is not getting reset with the new values. For the former, in guestbook_save.php you can simply do a session_unset (if you really want to clear all of them). However this does not handle an abnormals equence -- for example someone hits Back in the middle of the process. I don't understand why they are not getting set properly the second time around. It could be a condition in your code. I'd have to see the code to have an idea. Try stripping the code WAY down so you have a test_add.php with a 1- field form, and a test_review.php that displays that data and saves it in a session variable, and test_save.php that just displays what it receives in the session variables. If that still fails, post the code. If not, your problem lies in the difference between that and the original code. -- 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] 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 ttagag, and so on. stripslashes is specifically documented as handling only one round of backslashes -- do I need to call it in a loop? Thinking through whether this matters is tricky. In other words I can imagine classes of problems that the existing tools may or may not solve, and it's a bit of a chore to investigate so I was hoping someone else had already done so :-). Thanks for all of the comments. -- 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 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] 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] 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:
?php
$date = '9/8/2001';
list($mm, $dd, $yy) = explode('/', $date);
print(sprintf('%4d%02d%02d', $yy, $mm, $dd));
?
--
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: 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
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: ?php $ipaddr = localhost; # substitute the IP address here $fp = fsockopen($ipaddr, 3306, $errno, $errstr, 5.0); var_dump($fp, $errno, $errstr); if ($fp) fclose($fp); ? 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: [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 head area: print meta http-equiv=\Refresh\ content=\120\\n; If you want to refresh to an explicit URL: header(Refresh: 120; URL=http://...;); print meta http-equiv=\Refresh\ content=\120; URL=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. slapping head 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] 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
[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] 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
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] 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
