[PHP-DB] Re: Cannot connect to a MySQL DB using a Class
At 00:46 05/01/2006, you wrote: Message-ID: [EMAIL PROTECTED] To: php-db@lists.php.net Date: Wed, 04 Jan 2006 16:45:54 -0800 From: Todd Cary [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: CAnnot connect to a MySQL DB using a Class No doubt I am over looking something very simple, nevertheless I am baffled by not being able to connect to a MySQL DB. // Error produced here!! $this-db=mysql_connect($this-host,$this-user,$this-password); mysql_select_db($this-database); Surely you meant mysql_select_db($this-db); since that's what you connected to ? Cheers - Neil -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: Cannot connect to a MySQL DB using a Class
Neil - Thank you for noticing my typo. The actual PHP code has both choices with one commented out. When I constructed the message for the forum I selected the wrong one - not the one I actually am using. Todd Neil Smith [MVP, Digital media] wrote: At 00:46 05/01/2006, you wrote: Message-ID: [EMAIL PROTECTED] To: php-db@lists.php.net Date: Wed, 04 Jan 2006 16:45:54 -0800 From: Todd Cary [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: CAnnot connect to a MySQL DB using a Class No doubt I am over looking something very simple, nevertheless I am baffled by not being able to connect to a MySQL DB. // Error produced here!! $this-db=mysql_connect($this-host,$this-user,$this-password); mysql_select_db($this-database); Surely you meant mysql_select_db($this-db); since that's what you connected to ? Cheers - Neil -- Ariste Software 2200 D Street Ext Petaluma, CA 94952 (707) 773-4523 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Page Caching after DB Query
How can I force the browser to re-display the last dynamically created page when using the back button, for example, rather than re-issuing the query. Are there any complications because we are using the https protocol on Apache? David -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Page Caching after DB Query
/* for the archives */
Ah, it's in the manual, isn't it?
I was calling session_start() on the page, so the session.cache_limiter
value of 'nocache' in php.ini was overriding all attempts to cache the
page.
Calling session_cache_limiter('private') before session_start() did the
trick.
David
How can I force the browser to re-display the last dynamically created
page
when using the back button, for example, rather than re-issuing the
query.
Are there any complications because we are using the https protocol on
Apache?
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] var_dump and sizeof database entry?
Hello, This is stumping me something awful. I have searched the archive of this mailing list and google and the php and mysql websites with everything i can think of. I have a simple mysql table with some basic columns and a blob column that holds an image file. What I need to get is the size of this image file for use with an rss feed (the enclosure length parameter). In the simplest case, I thought I would just read the entire blob into a variable, and then I would be able to get the size of this variable. However, php does not seem to have a function to do this. Inexplicably, the var_dump command will actually dump the information I want, but it is very memory inefficient, because I get something like: [preview]= string(17888) ENTIRE CONTENTS OF BLOB HERE where all I really want is the 17888 value (for a 17.5 KB file). What I was wondering is if there is a simple way to get this information from mysql directly without having to 1) select the blob column and 2) do a var_dump with output buffering and parsing for the parenthetical file size, which seems very inefficient to me. any insight is greatly appreciated. Jordan -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: mysql_fix_privilege_tables error
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Carson Au) wrote: Hi Guys, I am a newbie and having a lot of trouble with PHP/MySQL lately... We have a number of PHP/MYSQL solutions developed on our server and I have the pleasure to maintain them... The copy of MySQL 3.23 has started crashing and refusing to start, so what I did was I backed up all the DBs and then reinstalled version 4, things seems to be working ok. Then I discovered this: http://www.educ.sfu.ca/phpbb2/ and in phpmyadmin I get this message: Warning: Your privilege table structure seem to be older than this MySQL version! Please run the script mysql_fix_privilege_tables that should be included in your MySQL server distribution to solve this problem! So I tried to do the following... $ sudo -s $ mysql_fix_privilege_tables mypassword And this is the errors I got: This scripts updates the mysql.user, mysql.db, mysql.host and the mysql.func table to MySQL 3.22.14 and above. This is needed if you want to use the new GRANT functions, CREATE AGGREAGATE FUNCTION or want to use the more secure passwords in 3.23 If you get Access denied errors, you should run this script again and give the MySQL root user password as a argument! If your tables are already up to date or partially up to date you will get some warnings about 'Duplicated column name'. You can safely ignore these! ERROR 1045: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) Creating Grant Alter and Index privileges if they don't exists You can ignore any Duplicate column errors ERROR 1045: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) Creating the new table and column privilege tables ERROR 1045: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) Changing name of columns_priv.Type - columns_priv.Column_priv You can ignore any errors from this ERROR 1045: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) Fixing the func table You can ignore any Duplicate column errors ERROR 1045: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) Any suggestion? I have checked the permission table using phpmyadmin and grant=Yes for root. Anything else I need to do differently? Regards, Cars Hi, I'm using MySQL 4.0.28. The syntax that finally worked for me was: mysql_fix_privilege_tables --password='my_password' The single quotes around the password seem mandatory! -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] var_dump and sizeof database entry?
I would do one of two things here: 1. add a size column to the db and have the image size added when inserting the image 2. run a trash script (either sql if your version support subselects or a little page) to get the size of the image and enter it into the size field Another option is to use select *, (length(image_fiedl)/1024) as Kb from table [where clause] to get the size Bastien From: Jordan Miller [EMAIL PROTECTED] To: PHP DB php-db@lists.php.net Subject: [PHP-DB] var_dump and sizeof database entry? Date: Thu, 5 Jan 2006 16:19:43 -0600 Hello, This is stumping me something awful. I have searched the archive of this mailing list and google and the php and mysql websites with everything i can think of. I have a simple mysql table with some basic columns and a blob column that holds an image file. What I need to get is the size of this image file for use with an rss feed (the enclosure length parameter). In the simplest case, I thought I would just read the entire blob into a variable, and then I would be able to get the size of this variable. However, php does not seem to have a function to do this. Inexplicably, the var_dump command will actually dump the information I want, but it is very memory inefficient, because I get something like: [preview]= string(17888) ENTIRE CONTENTS OF BLOB HERE where all I really want is the 17888 value (for a 17.5 KB file). What I was wondering is if there is a simple way to get this information from mysql directly without having to 1) select the blob column and 2) do a var_dump with output buffering and parsing for the parenthetical file size, which seems very inefficient to me. any insight is greatly appreciated. Jordan -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] var_dump and sizeof database entry?
whoa, that was EXACTLY what I needed. Thanks!! Jordan On Jan 5, 2006, at 6:14 PM, Bastien Koert wrote: select *, (length(image_fiedl)/1024) as Kb from table [where clause] to get the size Bastien -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. I'm also thinking about how to save passwords in the DB, not plaintext, but not one-way encrypted either. Any suggestions? How would I secure the database? I'm thinking some abstract process in code, or something -- security through obscurity. Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
CC saving is a bad idea on a web facing server...much better to let the user re-input the data each time. If your network allows it, store the data encrypted (using php's mcrypt/decrypt extension) on an separate extremely limited access, non-webfacing (ie internal) db/server that only allows inserts from the webfacing server. Hacking and the liability of being hacked is something to take very seriously. Also look into PCI regulatory compliance with regard to storing CC data on a server to be aware of any laws that can govern how you do this. Passwords: again use mcrypt Bastien From: Peter Beckman [EMAIL PROTECTED] To: PHP-DB Mailing List php-db@lists.php.net Subject: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption Date: Thu, 5 Jan 2006 20:27:57 -0500 (EST) So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. I'm also thinking about how to save passwords in the DB, not plaintext, but not one-way encrypted either. Any suggestions? How would I secure the database? I'm thinking some abstract process in code, or something -- security through obscurity. Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
Peter Beckman wrote: So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Why, is the first question I would ask you. First off, on a new order, why wouldn't you just save the authorization code, instead of the credit card number? That would be a lot easier. Secondly, you're opening yourself up to a _ton_ of lawsuits should anything go awry. Unless I had a _real_ good reason for storing their cc number, I wouldn't, despite the extra step. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
On Thu, 5 Jan 2006, John Meyer wrote: Peter Beckman wrote: So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Why, is the first question I would ask you. So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Think one-click. Why did Amazon patent one-click? Impulse buys -- the I want that, now factor. If you make 13 steps and 12 input boxes, the Impulse will probably pass, and you've lost your sale. Besides, the user can choose if they want you to save their card info. First off, on a new order, why wouldn't you just save the authorization code, instead of the credit card number? That would be a lot easier. Sure. But see my above point. I want to be able to re-charge it later when the user wants to. Secondly, you're opening yourself up to a _ton_ of lawsuits should anything go awry. Unless I had a _real_ good reason for storing their cc number, I wouldn't, despite the extra step. Yes yes, lawsuits, scary, etc. I was looking for technical solutions, i.e. maybe someone knows how USPS.com or Amazon.com or GoDaddy.com (do they?) does it. Or if it is all security via obscurity. Best solution yet: Public key encryption, with additional either secret word padding or using the users account password to pad/encrypt the card number (preventing a brute force attack, even if access to the DB is given). Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
On Fri, 6 Jan 2006, Julien Bonastre wrote: Any reason why you need to have reversible encryption on the password value?? No... I just prefer to assume that if someone gets my DB, they might try using user/pass pairs on banking sites, or paypal, or other ways, and if I can reversible encrypt the password, I can send them an email with their password, rather than changing it to something obscure and force them to change it again... Though at this point, I just decided to md5 the password and call it good enough. I'll just force them to change it if need be. Generally I simply create some hash from the password, using something akin to a MD5 or SHA1 hash of the password string. Or in my paranoid case I use the password string, plus all sorts of replicatable combinations of values such as length of password, username, registration date/time etc plus weird other fixed values I find around the place and environment variables etc, then I hash them.. A good idea; are you just careful then that you don't accidentally update the data without re-hasing your passwords? I am completely psychotic so don't mind me, when I was 15 I wrote my Perl driven website http://operation-scifi.com [still Perl driven member system and file-system based forum] and I had a real mangler function whereby I would extract each character of the password and hash it, then hash the hash with the other characters, plus the hash of them with said fixed values from server/user account details [age, location etc..] ... It was something in the vicinity of a O(6^n+1)th generation hash by the time I had finished where n is the length of the original password.. *laugh* Awesome! Maybe a bit overkill for password, but still very cool. Unfortunately that leaves things unreversable, and if someone got a hold of your data AND your code, they could reverse-engineer... It seems security is only as good as your weakest link -- obscure code, private key, etc... Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-wayencryption
From: Peter Beckman [EMAIL PROTECTED] To: Julien Bonastre [EMAIL PROTECTED] CC: php-db@lists.php.net Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-wayencryption Date: Thu, 5 Jan 2006 22:53:30 -0500 (EST) On Fri, 6 Jan 2006, Julien Bonastre wrote: Any reason why you need to have reversible encryption on the password value?? No... I just prefer to assume that if someone gets my DB, they might try using user/pass pairs on banking sites, or paypal, or other ways, and if I can reversible encrypt the password, I can send them an email with their password, rather than changing it to something obscure and force them to change it again... Though at this point, I just decided to md5 the password and call it good enough. I'll just force them to change it if need be. Really is the best way to handle it...change and force them to rechange when logging in again.. May I recommend that you SALT the hash value by pre/appending a random string to the value to prevent a straight dictionary attack. Bastien -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
On Fri, 6 Jan 2006, Julien Bonastre wrote: Any reason why you need to have reversible encryption on the password value?? No... I just prefer to assume that if someone gets my DB, they might try using user/pass pairs on banking sites, or paypal, or other ways, and if I can reversible encrypt the password, I can send them an email with their password, rather than changing it to something obscure and force them to change it again... Though at this point, I just decided to md5 the password and call it good enough. I'll just force them to change it if need be. Generally I simply create some hash from the password, using something akin to a MD5 or SHA1 hash of the password string. Or in my paranoid case I use the password string, plus all sorts of replicatable combinations of values such as length of password, username, registration date/time etc plus weird other fixed values I find around the place and environment variables etc, then I hash them.. A good idea; are you just careful then that you don't accidentally update the data without re-hasing your passwords? I am completely psychotic so don't mind me, when I was 15 I wrote my Perl driven website http://operation-scifi.com [still Perl driven member system and file-system based forum] and I had a real mangler function whereby I would extract each character of the password and hash it, then hash the hash with the other characters, plus the hash of them with said fixed values from server/user account details [age, location etc..] ... It was something in the vicinity of a O(6^n+1)th generation hash by the time I had finished where n is the length of the original password.. *laugh* Awesome! Maybe a bit overkill for password, but still very cool. Unfortunately that leaves things unreversable, and if someone got a hold of your data AND your code, they could reverse-engineer... It seems security is only as good as your weakest link -- obscure code, private key, etc... Well, I still consider it irreversable due to the fact that it is an MD5 hash therefore generating the plainttext from a given ciphertext is fairly slim unless as I mentioned certain dictionary plainttext words are kept catalogued somewhere they can match too. But with the sheer randomness of the plainttext this would never have been hashed before. So even if someone knows my algorithm and has somehow obtained not only the end result but also has the plainttext password and all the data I use intermediate to creating my final hash value AND they can recompute using all this the same final value. This still does not help them figure out HOW to reverse just a stored hash value which they do not know any of the values that were used in its encryption, ie the password or user details. Put simply: how do you reverse a hash? Its designed to be a one way function: I give you: fc3ff98e8c6a0d3087d515c0473f8677 86fb269d190d2c85f6e0468ceca42a20 First MD5 hash is the plainttext of hello world! the second is Hello world! One character difference, and if you do have an understanding of the inner workings of the MD5 function you will already know the implications a checksum works on and thereby it only requires a single one bit of difference [no pun intended] to create a vastly different checksum hash.. I am happy to place the security of my users within this field of near impossibility and believe I have done everything in my power to ensure even with the most simplest dictionary word password to start with, they end up with a far more complex end hash therefore avoiding the largest and by far easiest hash cracking method which is brute force dictionary matching. Meh, whats it all at the end of the day anyway.. Good questions about the credit card stuff though. I've encountered similiar issues but decided to simply delegate paypal.com.au's services to handling subscriptions, credit card payments etc... Their global, safe, established and it works. Its not perfect, but it'll do. For example a big problem is you can't really have variable monthly payments, say your site provides a service where you are sort of billed every month for what features you've accessed, premium services you've used, how long you used them for etc, much like your electricity bill or phone bill, well the only feature paypal provides is its fixed rate subscription system. Even with the API you can only really retrieve details and transaction records, you can really edit the rate behind the scenes. The only method is rather primitive and involves generating a link or form your user will be displayed on your site which they follow, linking to a subscription modification page on paypal with the new required values all entered in. Sure thats great but now thats the new rate per month. Not good if its a very variable or fluctuating sort of service you provide with extras or whatever.. The advantage? Paypal keeps all
