RE: [PHP] Re: POST-ing or GET-ing an array
You need to call start_session before accessing $_SESSION variables UNLESS you have PHP configured to automatically start_session (which is off by default). You need to start_sesion so that scripts that don't need $_SESSION don't go through the overhead of starting session. Jason -Original Message- From: Sascha Cunz [mailto:Sascha;GaNoAn.org] Sent: Tuesday, October 29, 2002 2:15 PM To: Nick Eby; [EMAIL PROTECTED] Subject: Re: [PHP] Re: POST-ing or GET-ing an array Hi, I disagree that serialize/unserialize is the way to go, unless you're absolutely completely sure that there will only be a relatively small number of things in the array. As somebody mentioned briefly, the get request is limited to a certain number of bytes, and the string representing your serialized array could easily get too large to send on a get request. imho the best option is to use the session, which somebody already mentioned but didn't really elaborate... $_SESSION['my_array'] = $my_array; Exactly. But just to mention it at this point: if you have script-output (echo, print, print_r etc.) before any operation on $_SESSION, you should call start_session() at the start of the script. (I don't know if recent versions of PHP still _need_ this) and on next_page (or any other page), you'd just use $_SESSION['my_array'] where you need. I would suggest, unsetting the array in the next_page (or whatever) after you don't need it anymore: unset($_SESSION['my_array']); Another option would be to send the request as a post, and serialize the array into a hidden variable in your form; that way you won't have to worry (as much) about size constraints. (a post request is also limited in size, but it's so large that you probably would never approach the limit.) /nick -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] for??????
I believe there is some confusion between columns (fields) and rows. LIMIT
is generally used to limit the returned rows, not fields. If you want only
specific columns then select only the ones you want SELECT
id,firstname,lastname,login FROM users ORDER BY lastname,firstname.
Jason
-Original Message-
From: Martin Hudec [mailto:corwin;corwin.sk]
Sent: Monday, October 28, 2002 10:38 AM
To: Bsantos PHP
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] for??
Hello Bsantos,
BP Now, I've created a funtion which controls how many fields (cols) may be
BP seen by user. Some like this:
BP function select_query ($fields, $table) {
BP $result = (SELECT $fileds FROM $table);
BP }
maybe mistype in SELECT fileds should be fieldsalso try using
select_query() without that space between...i suppose you will
have something like select_query(email,name,userlist)
BP Well, I hould like to control how many fields my query will use.
for example you will want first ten fields...then add
to query LIMIT 0,10 (it will start from first field, and it will
select ten fields)
BP For example: if I call select_query('id,username,email', 'users');
BP I want to know that there was selected 3 cols. so I can later do some
like
BP this:
well three cols are not difficult...just from what position u want to
have them (see LIMIT above)...
BP for ($j=0;$j$number_of_selected_cols_minus_one;$j++) {
BP echotd$list[$j]/td;
BP ... and that's it. By the way!! Is this late statement correct?!?!
to this for statement...why are you doing minus one?...for example if
you have 10 selected cols...it will do that echo ten times for each
$jnot nine as in your original statement...you will have one $j
extra...
okay hope it helps for now
--
Best regards,
Martinmailto:corwin;corwin.sk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] extract($_POST)
You can still create a sub-query to do the damage.
Jason
-Original Message-
From: John W. Holmes [mailto:holmes072000;charter.net]
Sent: Friday, October 25, 2002 4:01 PM
To: 'Rick Emery'; 'Chris Boget'; [EMAIL PROTECTED]; 'Monty'
Subject: RE: [PHP] extract($_POST)
No, this can't happen. There can only be one SQL query per
mysql_query().
Google for SQL injection or something and I'm sure you'll find examples.
---John Holmes...
-Original Message-
From: Rick Emery [mailto:remery;emeryloftus.com]
Sent: Friday, October 25, 2002 4:59 PM
To: Chris Boget; [EMAIL PROTECTED]; Monty
Subject: Re: [PHP] extract($_POST)
Lets say you have a statement like:
$query = SELECT * FROM mytable WHERE firstname=$firstname;
And if $firstname is set to:
xyz; DELETE FROM mytable
Then this is executed as: SELECT* FROM mytable WHERE
firstname=xyz;DELETE FROM mytable
This can wipe out your table...a bad thing...
- Original Message -
From: Chris Boget [EMAIL PROTECTED]
To: Rick Emery [EMAIL PROTECTED];
[EMAIL PROTECTED];
Monty
[EMAIL PROTECTED]
Sent: Friday, October 25, 2002 3:41 PM
Subject: Re: [PHP] extract($_POST)
This thread has been great! I've learned so much useful stuff.
For instance, if you expect a variable called $firstname to contain
a name to be stored in a SQL database, be certain it does not
contain
SQL commands which can damage your database.
This is another thing I'd be interested in hearing more about. If all
you
are doing is storing and retrieving data, what commands could possibly
be defined that could damage your database?
$firstName = Chris;
mysql_query( INSERT INTO names ( first_name ) VALUES ( \$firstName\
)
);
$result = mysql_query( SELECT first_name FROM names );
while( $dataArray = mysql_fetch_assoc( $result )) {
echo $dataArray[first_name]
}
If $firstName was set by a form submission, what malicious SQL code
could
damage your database? All you are doing is storing, retreiving and
displaying
data...
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re[2]: [PHP] DB speed
Checkout osdb, it's the Open Source Database Benchmark it supports Postgres and MySQL and is available at http://osdb.sourceforge.net. To test Postgres and MySQL you will need both installed on the machine you try to compile from, you will need to compile with --with-mysql and --with-postgresql and you may need to specify the install points (i.e. ./configure --with-mysql=/usr/local --with-postgresql=/usr/local). I successfully compiled it on FreeBSD 4.6 but compile failed on HP-UX 11.11. Jason -Original Message- From: Uros Gruber [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 2:29 PM To: tuxen Cc: [EMAIL PROTECTED] Subject: Re[2]: [PHP] DB speed Hi! I make some more test for this. When i enable pconect (persistant) the result amazed me. PGSQL Total time: 0.0070 Execution time: 0.0034 MySQL Total time: 0.0072 Execution time: 0.0027 Now PGSQL is as fast as mysql or maybe a lile slower. So is this normal that non-persistant is so much overhead for pg. Is there any tools to check this. Or is some kind of a bug in php. I use 4.2.3. And pg is 7.2.1. Can somebody make some test. I can send script what i've run. -- tia, Urosmailto:[EMAIL PROTECTED] Friday, October 11, 2002, 5:09:31 AM, you wrote: t I think i read something a while ago, about mysql being faster, having t less features, but postgres being a little slower but able to handle t LARGE databases better than mysql. I could be wrong, so dont take my t word for it. At the end of the day they are both good db's. t On Thu, 2002-10-10 at 09:02, Simon Taylor wrote: Well obviously - cos MySQL rocks!!, but seriously I also did some tests and got variable results from different db's - even got an odbc connection to access to run faster than mysql at one stage!! - something tells me there are other factors contributing.. Cheers Simon -Original Message- From: Uros Gruber [mailto:[EMAIL PROTECTED]] Sent: 10 October 2002 14:17 To: [EMAIL PROTECTED] Subject: [PHP] DB speed Hi! I'm making some testing over DB.php (PEAR) And i wan't to know if this is normal. I've made some script where I connect do SQL server and execute one simple (1row) query. I use pgsql and mysql. tables and indexes are same for both servers. So test table is identical Whe i execute those script i get some timing results PGSQL Total time: 0.0576 Execution time: 0.0185 MySQL Total time: 0.0086 Execution time: 0.0028 Time is in seconds. My machine is PIII 333 MHz with 128MB RAM. I table is only 3 rows of data. I want to know why is sucsh diference. Both servers runing with socket connections and using connnect (non-persistant) -- tia, Uros mailto:[EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encrypting passwords in a flat file before import
The potential problem with a firewall is your web server must be able to connect to the database, that means if someone gets sloppy in the PHP code or just doesn't realize something is a security issue OR there is an exploit found for apache or PHP the attacker can get access to your server without ever being blocked by the firewall. I see your point as well however if you are going to bother to encrypt the passwords why not use a more secure method? If passwords are already encrypted in the database it is trivial to write a tool to decrypt them, convert them to an md5 hash and update the passwords. Forcing the user to change passwords is a good idea, however I would still use a hash instead of reversible encryption because it is easy to implement and increases security transparently to the users and I can think of no good reason to need to know what the users passwords are (keeps system administrators as well as attackers honest). This is not hostile, I just come from system admin background and believe in making an application more secure if it doesn't affect the end user adversly :) Jason -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 2:48 PM To: 'SHEETS,JASON (HP-Boise,ex1)'; Scott Fletcher; [EMAIL PROTECTED] Subject: RE: [PHP] Encrypting passwords in a flat file before import Hi! I don't see yours in the PHP newsgroup. I understand what you meant and I don't have a problem with it. Problem is the password had to be changed at every 5th login. We have SSL features for the duration of the login period. So, the encrypt and decrypt will do fine and only the server will do that, not the end-user or their software. The login prompt become unavailable if the SSL connection is invalid. We also have a firewall, so cracking the database get harder. -Original Message- From: SHEETS,JASON (HP-Boise,ex1) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 4:35 PM To: 'Scott Fletcher'; [EMAIL PROTECTED] Subject: RE: [PHP] Encrypting passwords in a flat file before import Storing passwords in MD5 or another hash is an excellent idea because it is generally not possible to decrypt them (if the user uses a bad password they can be brute forced but you can only do so much). By storing passwords in MD5 you protect your users passwords, if your database gets cracked their passwords are still relatively secure. You generally should not use a reversible encryption technique to store something like user passwords, the reason being that in order to decrypt the passwords you must store the encryption key in your code, when someone gets access to your code (which they will or at least you must assume they will) all they have to do is look in your code for your encryption key, after that decrypting your user's passwords is trivial. The worst thing is most users use the same password for almost everything that means that many of their other accounts are now compromised and they may not even know it. It can be argued the user should use a more secure password and not use the same one in many places however the user is a being of convenience and is unlikely to remember more than one password anyway :) In short this has been covered probably thousands of times on this list but I did not want a newer user to make the mistake of using an insecure method of storing passwords, either putting them in the DB in plain text or using a reversible encryption technique that is equally insecure because of the implementation. Jason Sheets, CCNA, MCSE -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 2:24 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Encrypting passwords in a flat file before import I was comparing it to what I was thinking about. Like if the field in the table (database) have a username and password. Then you encrypt it with features like this, then how can it be de-crypt if I had like a thousand users account. It was just a thought in my mind. Now based on your responses and feedback. It seem that the md5() is such a bad idea and instead, using mcrypt function would help. Marco Tabini [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I think that generally you do not want passwords to be decryptable. What I normally do is try to encrypt whatever the user enters as a password and compare the resulting encrypted string with what's in the database to make sure they correspond. If the encrypting function is univocal (and md5 is) then the correct password will always return the same encrypted string. On Wed, 2002-10-09 at 16:06, Scott Fletcher wrote: Can it be de-encrypt??? I don't see how since you just use the function md5(). Marek Kilimajer [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If you don't need the file to be changed to contain md5 encrypted
RE: [PHP] Encrypting passwords in a flat file before import
Storing passwords in MD5 or another hash is an excellent idea because it is generally not possible to decrypt them (if the user uses a bad password they can be brute forced but you can only do so much). By storing passwords in MD5 you protect your users passwords, if your database gets cracked their passwords are still relatively secure. You generally should not use a reversible encryption technique to store something like user passwords, the reason being that in order to decrypt the passwords you must store the encryption key in your code, when someone gets access to your code (which they will or at least you must assume they will) all they have to do is look in your code for your encryption key, after that decrypting your user's passwords is trivial. The worst thing is most users use the same password for almost everything that means that many of their other accounts are now compromised and they may not even know it. It can be argued the user should use a more secure password and not use the same one in many places however the user is a being of convenience and is unlikely to remember more than one password anyway :) In short this has been covered probably thousands of times on this list but I did not want a newer user to make the mistake of using an insecure method of storing passwords, either putting them in the DB in plain text or using a reversible encryption technique that is equally insecure because of the implementation. Jason Sheets, CCNA, MCSE -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 2:24 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Encrypting passwords in a flat file before import I was comparing it to what I was thinking about. Like if the field in the table (database) have a username and password. Then you encrypt it with features like this, then how can it be de-crypt if I had like a thousand users account. It was just a thought in my mind. Now based on your responses and feedback. It seem that the md5() is such a bad idea and instead, using mcrypt function would help. Marco Tabini [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I think that generally you do not want passwords to be decryptable. What I normally do is try to encrypt whatever the user enters as a password and compare the resulting encrypted string with what's in the database to make sure they correspond. If the encrypting function is univocal (and md5 is) then the correct password will always return the same encrypted string. On Wed, 2002-10-09 at 16:06, Scott Fletcher wrote: Can it be de-encrypt??? I don't see how since you just use the function md5(). Marek Kilimajer [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If you don't need the file to be changed to contain md5 encrypted passwords use *fgetcsv() *to read the contenta, then use *md5()* on the password and insert it into database using mysql_query. No need to write a new file. Verdon Vaillancourt wrote: Hi, I hope this question isn't too basic... I have a flat file (CSV) that I want to import into a mySQL db via phpMyAdmin. The file has about 1200 rows and is in a format like: value,value,password,value,value,etc The passwords are in clear text. I need them to be encrypted in md5. Is there any advice out there as to how I could process this flat-file before I import into my db or after the fact? Thanks, verdon Ps. Please cc me if replying to list as I am on digest mode -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
