Re: [PHP-DB] Re: global not solving my problem
On Sun, Nov 30, 2008 at 11:48 AM, Fred Silsbee fredsils...@yahoo.com wrote: problem solved...used a session: [...] any harm in this? Session hijacking is possible, though you can take steps to minimize the risk. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] MySQLi connections
-- Forwarded message -- From: Fergus Gibson [EMAIL PROTECTED] Date: Fri, Nov 28, 2008 at 12:47 AM Subject: Re: Fwd: Fwd: [PHP-DB] MySQLi connections To: J. Hill [EMAIL PROTECTED] On Wed, Nov 26, 2008 at 9:38 PM, J. Hill [EMAIL PROTECTED] wrote: I understand there are many cases where database abstraction layers are preferable, but in some applications which are heavily dependent on a specific database's unique functions, it seems to me that avoiding abstraction would decrease the complexity and improve the performance of the application -- at the cost of making it more difficult to switch database servers. I don't necessarily mean something pre-built. You can create your own abstraction by writing a class composed of the database object you want to use. As long as you have a consistent interface and use encapsulation, you get all the benefits of abstraction. It actually hides complexity at the same time that it makes it easier if you need to migrate to a different database server in the future. The key to abstraction is to hide everything but the interface from the rest of the application so that the other elements can't become dependent on the specific implementation. [...] instead just put all the core mysqli calls into a library -- cleaner than scattering them across all the files. That's pretty much the same thing. ;) The point is that only one component of your application should have to know about the database. The rest of it should be completely ignorant. That way, you only have to update that one component in a migration. What sort of object or functions you use to do the actual database operations is not my point. It's about ensuring that the rest of your application never knows if you're using MySQL, SQL Server, Oracle, Postgres, or something else. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] re:database tables relations advice
On Thu, Nov 27, 2008 at 11:19 AM, Bastien Koert [EMAIL PROTECTED] wrote: 2. It is possible to use the application to handle the keys instead of the database, it involves more work around key checking / validation before creating or updating records, but it can be done if the INNODB table type is not accessible to you for some reason. Yes, but generally foreign key constraints are preferable. The database server is compiled in native code, so it'll be much faster at handling this issue; and it may avoid the necessity of your script submitting multiple queries to resolve the foreign key issues. A bigger issue though is that the implementation of foreign key constraints on the server will have been exhaustively tested. Reinventing the wheel in your own PHP code may introduce bugs that cause loss or damage to your data. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: Fwd: [PHP-DB] MySQLi not closing connections
-- Forwarded message --
From: Fergus Gibson [EMAIL PROTECTED]
Date: Wed, Nov 26, 2008 at 11:34 AM
Subject: Re: Fwd: [PHP-DB] MySQLi not closing connections
To: Chris [EMAIL PROTECTED]
On Tue, Nov 25, 2008 at 1:39 PM, Chris [EMAIL PROTECTED] wrote:
Not really true.
pconnect leaves the connection open ('persistent'). From the manual: when
connecting, the function would first try to find a (persistent) link that's
already open with the same host, username and password.
Here's a citation from Zend.com:
The mysql_pconnect() function was designed to provide a mechanism for
reducing the cost of establishing and closing connections to the MySQL
server. Unfortunately, due to an interaction between the architecture
of the Apache server and the architecture of PHP, high traffic on a
site that used pconnects could quickly clog up the MySQL server with
many unused connections that could prevent many of the active
connections from accessing the database.
http://devzone.zend.com/node/view/id/686#fn1
I understand how mysql_pconnect() is meant to work, which is what you
quote from the documentation, but I also believe the claims that there
is an incompatibility between Apache specifically and
mysql_pconnect().
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP-DB] MySQLi not closing connections
-- Forwarded message -- From: Fergus Gibson [EMAIL PROTECTED] Date: Wed, Nov 26, 2008 at 11:50 AM Subject: Re: [PHP-DB] MySQLi not closing connections To: Jonathan Langevin [EMAIL PROTECTED] On Wed, Nov 26, 2008 at 10:36 AM, Jonathan Langevin [EMAIL PROTECTED] wrote: I would normally think there were problems elsewhere in the code, if the issues didn't stop once I comment out the logging functionality. I don't see anything that would account for your symptoms in that code snippet, but it's important to remember that sometimes code in one place can interact with code in another place to expose a bug. When your application uses ext/mysql, it uses only built-in functions. It's only when it uses ext/mysqli that it uses a customized sub-class. I would look in that subclass for the problem. But honestly, I'm flummoxed, Jon. Since non-persistent connections should automatically close when the script ends (normally or for an error), I don't understand why the connections are remaining open only when logging is enabled. I would expect it to be a by-product of the connection process instead or a bug. Does the application use mysql_real_connect() or mysqli_real_connect() at all? If so, are you using a version of PHP pre-5.3? There is a bug and a bug fix for it. http://bugs.mysql.com/bug.php?id=33831 http://bugs.php.net/bug.php?id=39457 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: Fwd: [PHP-DB] MySQLi connections
-- Forwarded message -- From: Fergus Gibson [EMAIL PROTECTED] Date: Wed, Nov 26, 2008 at 11:55 AM Subject: Re: Fwd: [PHP-DB] MySQLi connections To: J. Hill [EMAIL PROTECTED] On Tue, Nov 25, 2008 at 3:12 PM, J. Hill [EMAIL PROTECTED] wrote: I am used to creating a class and a database handle for functions to use, but I inherited an intranet that just uses a single $mysqli = mysqli_connect in a global main file and the just uses global $mysqli in all of it's functions (several hundred) that interact with the database. [...] Could anyone point me towards any documentation on why such a structure is bad? It's bad if you ever want to use something other than mysqli! Imagine your company switching to another database server. You'd have to rewrite code in hundreds of functions! This is where a database wrapper class could have saved a lot of headache. As it is, the least expensive way to migrate databases permitted by the original programmer's choice would be to write an adapter class and substitute it in place of mysqli and hope there are no SQL incompatibilities. Not very efficient though. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fwd: Fwd: [PHP-DB] MySQLi connections
On Wed, Nov 26, 2008 at 1:45 PM, Chris [EMAIL PROTECTED] wrote: It's bad if you ever want to use something other than mysqli! Imagine your company switching to another database server. You'd have to rewrite code in hundreds of functions! [...] You're going to have a lot more problems with changing db servers than just search/replac'ing mysqli calls. Eg - 'LIMIT' - the format is different for postgres, mssql doesn't have it nor does oracle. In case it was unclear, that's precisely my point. Abstraction would make it much easier to change databases later if need be because all the SQL could be contained in a class with a simple interface exposed to the rest of the application. Switching databases would only involve making changes to that class then, which is much easier than trying to update many functions in many different places. In the current scheme Mr. Hill describes, each function is tightly coupled to the database because they all feed SQL to the mysqli class directly. He asked what's wrong with the scheme, and I think it's fair to say that's the problem. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP-DB] MySQLi not closing connections
Darn it. Didn't change the e-mail recipient to be the list. -- Forwarded message -- From: Fergus Gibson [EMAIL PROTECTED] Date: Tue, Nov 25, 2008 at 12:02 PM Subject: Re: [PHP-DB] MySQLi not closing connections To: Jonathan Langevin [EMAIL PROTECTED] On Tue, Nov 25, 2008 at 6:31 AM, Jonathan Langevin [EMAIL PROTECTED] wrote: The problem is, this activity log, when enabled, results in all MySQL connections being used, and we run out of open connections. I'm not sure where the error is. Our config.php, when included, initializes the MySQL or MySQLi connection as decided by the script that included the config. [...] Hi, Jon. It's difficult to offer specific replies without specific code, but I did raise my eyebrow at the notion of mixing the mysql and mysqli extensions in your application. I'm guessing you've inherited some pretty messy code that is time-consuming to refactor. Is any of the code working against the mysql extension calling mysql_pconnect() to create a persistent database connection? Connections so opened CANNOT be closed using mysql_close(). I have never written an application using persistent connections, but I did get hired at a company where the other programmers describe the same problem you're having (a proliferation of connections that overwhelmed the server). They blamed mysql_pconnect() and the lead programmer said that after he banned the use of that function, the problem went away completely. A comment to the PHP documentation suggests this is the result of a bad interaction between Apache and PHP. Within the same file, a shutdown function is registered to automatically close the MySQL or MySQLi connection at the end of script execution (based on which connection was initialized to begin with). This should not be necessary. The script will close all open resources when it terminates anyway. The reason for having and using close functions is to free resources while the script is still running. As mentioned above, persistent connections created by mysql_pconnect() cannot be closed by mysql_close() under any circumstances, nor will they automatically close on completion of the script. I believe that's your problem. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] MySQLi not closing connections
On Tue, Nov 25, 2008 at 10:27 AM, Jack Mays [EMAIL PROTECTED] wrote: I'm not sure why the connections are staying open, but I would suggest using mysqli_real_connect with the flag to timout connections. [...] If this is way off base, let me know. Jack, I think Jon shouldn't implement this suggestion. Adjusting the timeout isn't a good way to address spawning a plethora of connections. Jon should find and fix the bug that is causing so many connections to be opened or to persist in the first place rather than simply asking the database to close connections more quickly (your suggestion). Opening or maintaining all those connections is a big waste of resources in the first place. Logically, it's also bad form to make the connections close faster than they should because that means more resources will be used setting up and tearing down connections. I'm all for timeout tuning, but it's a separate issue here. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Multiple Update SQL Statements Execution
On Wed, Nov 19, 2008 at 5:55 AM, Alice Wei [EMAIL PROTECTED] wrote:
I am inquiring on this list to see if it is possible to create a script that
takes multiple update statements without my having to write one SQL
statement for each of the updates.
I'm not sure I understand your question. It is certainly possible to
write one query that updates multiple rows at once. In other cases,
you can use prepared statements and bound variables. If all you need
to do is repeat a query of the same structure with different values, a
prepared statement would be faster and mean cleaner code than sending
repeated queries.
Without more specific info from you, I don't think I can give a better
answer than this. I've never worked with Microsoft SQL Server, so I
doubt there's anything I can tell you about that in particular.
I have a scenario of which I create a table of some sort with some existing
information using Flex, and what I am told by my client is that no matter how
many records there are on the screen, the users should be able to update any
up to all the entries by simply pushing a button. I use Microsoft SQL, which
I think that it does allow multiple update query execution. The problem is
that I might have to come up with some method to accept all the POST
variables the user provides into the script.
Let's see. If your POST includes the IDs of the rows you want to
change and the value you want to update, it could go something like
this. Note that I haven't tested it, so it might contain an error.
I'm just trying to provide an illustration of the approach.
?php
/*
SKIPPED: connect to your database as appropriate. Below I show using
the PDO extension to escape the incoming data using the quote()
method. If you are using the mssql extension instead, there is no
escape function (!) so you'll have to decide how best to escape the
data. That's reason enough for me to prefer PDO.
If you don't know what I'm talking about here, you should study SQL
injection until you're sure you fully understand. Otherwise you will
produce very vulnerable code.
*/
$sql = UPDATE sometable SET somecolumn = ' .
$pdo-quote($_POST['field']) . ' WHERE id IN (
. implode(',' $_POST['id']) . );
/*
Send this query to your database as appropriate. It will set
'somecolumn' to the value of $_POST['field'] where the ID is in the
list. In this case the form should submit the $_POST['id'] value as
an array, which can be done by using setting the HTML name attribute
to id[] (e.g. name=id[]).
*/
?
Does this help?
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Can MySql handle Large data?
On Mon, Nov 17, 2008 at 9:15 AM, Abah Joseph [EMAIL PROTECTED] wrote: The question came to my mind is, How did large website like Yahoo handle such data? Sure. Yahoo users may be more than 20 millions users or so. Very large data sets are often partitioned in some way so that a given lookup doesn't have to be performed against the entire data set. That's quite an expansive topic in fact. http://en.wikipedia.org/wiki/Partition_(database) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] sql injections/best practises
On Mon, Nov 10, 2008 at 8:49 AM, mignon hunter [EMAIL PROTECTED] wrote: One other question. Our current site is written in jsp with Oracle. I'd like to use PHP. Do you have any thoughts on this? Your post, mignon, was pretty clearly directed to Christopher, but I hope neither of you will be unhappy if I make my own comment. I look forward to seeing what Christopher thinks as well, but I do have some thoughts on this. First, I will say that I have never worked with JSP. I have worked with Java, and I rather enjoy it, but I have not travelled down any of the JSP trail. For that reason, I'm not going to attempt to assess JSP specifically, other than to say that it seems rather more time-consuming to learn than PHP. There is a simple reason that I choose PHP exclusively for web development. It has nothing to do with any intrinsic value of PHP. I actually think PHP is the worst designed platform I've ever worked with. There is so much about it I really don't like. But it has one overriding strength: it's everywhere. It's simple to integrate with any server, it's widely available, and hosting for other technologies like JSP, Ruby, and Python tends to be more expensive than PHP. And don't even get me started on ASP and ASP.Net, which are only truly supported on (shudder) MS servers. Now all of this said, I am leery of your idea to switch to PHP for this application you are working on. If you're not planning to move servers, the wider support for PHP isn't an advantage at all. Switching technologies because you think PHP is somehow cooler is a poor justification for what could be a costly exercise for the client, so you ought to have a really practical explanation. Why don't you want to continue working with JSP? Is there really a problem in using that platform? We're not really using Jsp as it was intended ( like using classes ) and I think it has alot of overhead and is overkill. It seems Php would be a better choice for imbedded html. This is probably true, but I am no authority on JSP. But in most cases, embedding PHP in HTML is not a best practice. Most professionals agree that there is a real value in separating presentation (HTML in this case) from logic (the PHP code). This is something all the frameworks attempt to help you do. This same idea was the impetus for the rise of model-view-controller (MVC) design pattern, its later application to web projects, and the development of Cascading Stylesheets (CSS) to separate presentation of web content from structure (HTML). As I mentioned previously, I am a little reluctant to use frameworks. For this reason I have implemented my own simple template script that allows me to put all my PHP logic in one file and all my presentation in a separate template file. My approach is similar to that of Brian Lozer. Brian is the author of bTemplate, but abandoned its development when he hit upon the real weakness in template engines and frameworks. Here's a link to his article on the subject. I'm not suggesting anyone use bTemplate; I'm encouraging people to understand why he decided it wasn't productive to use a convention template engine in the first place. http://massassi.com/php/articles/template_engines/ All the above notwithstanding, there's always an argument for saying a script is so simple the benefits of abstraction or design patterns or MVC are not of much value. But I think there are very few applications where this is true, and worst of all, I tend to find that even if you start off thinking that something is so simple and straightforward you should just bang it out in the most simple and direct way, you'll end up regretting it because the concept wasn't as simple as you thought or because the client keeps adding on to his original goal for the script 'til it becomes a messy monster you wished you designed properly in the first place... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Joomla MySQL query performance affected by anything non-server related?
On Wed, Nov 5, 2008 at 2:17 PM, Chris [EMAIL PROTECTED] wrote: Too many customers on the same server imo. 600 hits a day is nothing and if it takes 7 secs to update one column, that's just plain ridiculous. I agree with this consensus, and I agree that it's not clear how you would prove this. Where I differ with my fellows here is that I don't think proving it is an issue. I suspect they know the problem and they are blowing smoke, so it's not a question of proving anything. Simply call their bullshit in a professional and respectful way. But I'm not sure what the point of that is, really. You're using shared hosting, so this is kinda how it goes. I doubt any shared host will guarantee any sort of performance. You get a small share of an unspecific set of hardware with an unspecified number of other customers. Shared hosting is generally geared to hosting small sites of static pages. If you're hitting the performance wall, it's probably time to look at setting up a dedicated server. One thing that hasn't been suggested is that you could ask if they have query caching turned on for the server. Querying caching might help a little bit by relieving load on the database server. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Joomla MySQL query performance affected by anything non-server related?
On Sun, Nov 9, 2008 at 11:58 AM, TG [EMAIL PROTECTED] wrote: Shared hosting is fine.. I don't mind a little slow every now and then. For what this customer needs, a full dedicated server is total overkill. But the big problem here is that if you exceed a certain amount of CPU and/or slow query time in a given 60 second window, your site visitors get a big message saying CPU/Queries Exceeded! and they disable your account for 5-10 mins. [...] It doesn't sound like you think that's fine. It sounds like you have a problem with it. A dedicated server will solve that problem. Your only other realistic option is to dump this provider for another one. But there's no guarantee you won't have exactly the same problem or worse on someone else's shared server. The point is that shared hosting is something you don't control. With a dedicated server, you can call all the shots. Yes, it's expensive, but it's a trade-off. I've this sort of bullcrap from other hosts before. It's not limited to one host. It happens. A company I worked for stopped working with clients who wanted to put our application on shared hosting because it was too much of a headache. One client, for example, had his site disabled because the host felt it generated too many database queries. Um, well, they didn't publish anything about that in their ToS. You just sign up, roll the dice, and discover whether the host will work for you. And in the process, you've got a lot of PITA. So I don't recommend a shared host for providing a database-driven application of any significant size. Good luck trying to persuade your chosen host to amend their policies or improve their server. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] sql injections/best practises
On Fri, Nov 7, 2008 at 3:39 PM, Christopher Jones [EMAIL PROTECTED] wrote: mignon hunter wrote: I'm am trying to find some definitive best practises on database connections with php on both mysql and oracle. Most security issues come back to a simple concept. Assume anything in your scripts that is not a constant or literal to be a threat. That means any and all user submitted data is a potential attack. Ideally you should also assume that any and all data read in from the database or files is a potential attack. Assume everything is tainted. Your job then is to clean any and all input through inspection and filtering before you use it. I recommend the book Essential PHP Security by Chris Shiflett (ISBN 0-596-00656-X). It deals with database security and more. I would be happy to go into more detail on this or provide examples if it would be helpful. For example - what's the best usage - prepared statements? And does it have to be php 5? I need preferably a one stop shop as opposed to looking at dozens of different places. Can you advise a particular book? Website? Prepared statements will prevent SQL injection, but that is only one potential vector for attack. Keep in mind too that prepared statements are not necessary to prevent SQL injection and they aren't always the most appropriate way to do it. That said, they are the simplest way to protect your database. I'll outline a way that a database was used to attack an application. The attack wasn't particularly dangerous, but it was embarrassing for the company involved. In this case, the application took form input from a site visitor and saved it in the database. Then the site owner could retrieve the input and view it. Unfortunately, some visitors decided to put script tags in containing a Javascript redirect. Since the application trusted the data coming back from the database (not a best practice), it didn't attempt to filter it in anyway before sending it to the browser. The result was that when the site owner tried to retrieve the form submission data, he would find himself redirect to another website of the attacker's choosing. While no data was compromised in the attack, it did raise doubts about the security of that company's products. This kind of attack could easily be prevented by assuming that the data coming out of the database is tainted and then filtering it with htmlentities(). The result of that would have been that the script didn't run and didn't redirect the browser. This was the solution that the company implemented. I hope this example highlights why it's important to have a full understanding of security and related best practices. Just understanding methods to defeat SQL injection is not enough to ensure that your application is secure, and the aforementioned book will give you a security mindset that you can apply to all threat vectors. You also asked about PHP versions. I do recommend you use PHP 5. As mentioned, PHP 4.4.9 is the last release of PHP 4. There is no promise to address any further security issues in PHP 4 if they are discovered. PHP 5 also has other, non-security advantages over PHP 4. Most notable is a robust object model for we OOP types, but I also like decisions they made to bundle in certain modules missing from PHP 4. Thanks in advance. PS I would like to switch the current site from jsp to php. I was going to look into Zend IDE. Comments? Suggestions? Ugh. That's my comment. I assume we're discussion Neon here, the new Eclipse-based Zend Studio. The installation is huge and bloated, and I find it doesn't work very well at all for remote files over FTP. I really didn't care for it. If you love Eclipse, though, you will probably like it. I believe there's a free trial of the Studio, so you should try it rather than listening too much to opinions from the peanut gallery. I use UEStudio. It's not perfect, but it's a very robust, general programmers' editor. It's much faster and it makes difficult Eclipse tasks easy. It also has full Javascript scripting built into it, so it's very extensible. You can download a trial: http://www.ultraedit.com/downloads/uestudio_download.html Depending on the site needs, consider a DB abstraction layer or a framework. You can rely on frameworks to provide security to your application, but keep in mind that frameworks can contain vulnerabilities and bugs. They are made by people who can make mistakes. More significantly, if you are making an intensive application, you may find it reaches a point where the framework isn't scalable. I love and use abstraction, but abstraction does come with a performance price. For simple things, this cost is so slight you won't even notice it; but there is a point where the cost becomes significant. There's no simple way to evaluate that, though, because it depends on so many factors: traffic, server resources, specifics of the application, etc. I tend to stay away from frameworks
Re: [PHP-DB] pagination php mysql
On Sun, Oct 19, 2008 at 5:38 PM, [EMAIL PROTECTED] wrote: [...] First method is slower but more secure. Second is speediest but it can have more failures because are session vars or cookies. It depends of your control errors and also the visits profile. I'm not sure what you're trying to say here. There shouldn't be any errors in session variables and sessions needn't rely on cookies for propagation, that's just the default configuration. It's true that sessions can be hijacked, but the danger is slight and easily mitigated. The round trips on the database for your alternative scheme would be terribly unscalable. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] MySQL stored procedures OUT or INOUT parameters
2008/10/10 Post-No-Reply TUDBC [EMAIL PROTECTED]: By using TUDBC (http://www.tudbc.org), you can call stored procedures easily. Your post was an excellent answer to the question, How do I call stored procedures easily with TUDBC? Unfortunately, that is not what the original poster asked. In fact, no one has ever asked that question on this list. Ever. Posting to the list from a generic no-reply address seems pretty rude. But setting aside the irrelevance of your post, the example does not seem EZ at all. In fact, it seems quite a bit more complicated than the comparable code for PDO or mysqli, not to mention both unnecessarily verbose and simultaneously cryptic. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Problem with updating MySQL table
Hi, Jason. Do you realize this code is wide open for an SQL injection
attack? The problem could easily be addressed by using a prepared query
instead. For more details, check the mysqli documentation.
Jason Pruim wrote:
The problem is when I am attempting to update some of the info, it
erases the info in the field.
Anyone got a clue as to what is going on? :)
I'm not sure I understand. You mean that some of the fields that should
receive content in the update do not do so? Why not echo $sql and then
submit the form so that you can see the query being sent to your
database? That will probably help you solve the problem. Odds are
there is something wrong with your query.
You'd never want to echo an SQL query in a production environment, but
since this is in development, I assume you needn't worry about that.
You block of $variable = $_POST['key']; is a complete waste of time,
BTW. Why create another copy of the data? You could just as easily use
set FName = '{$_POST['txtFName']}'... That would also make your
injection vulnerability more obvious to you.
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Problem with updating MySQL table
YVES SUCAET wrote:
One suggestion: you may want put mysql_real_escape_string() wrappers
around
all those $_POST[] fields to prevent SQL hijacking of your site.
[...]
mysqli_query($link, $sql) or die(Could not update... .
Yves, he's using mysqli, not mysql. You should not mix those functions.
What he should do is this:
?php
$sql = UPDATE `schreur` set FName=?, LName=?,
email=?, Business=?, Address1=?,
City=?, State=?, Zip=?, Coffee=?,
subscribed=?, date=?, IPAddress=?,
Meeting=? WHERE record=?;
$statement = mysqli_prepare($link, $sql);
mysqli_stmt_bind_param($statement,
'sisssi',
$_POST['txtFName'],
$_POST['txtLName'],
// etc..
);
mysqli_stmt_execute($statement);
?
Personally, I find the object style much easier to use than this
procedural style, but I am just being consistent with his code. Using a
prepare query will escape all necessary data automatically, provided
your string of types ('sisssi') is correct.
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Problem with updating MySQL table
Jason Pruim wrote: I plan to wrap the $_POST's into something to protect against some issues like that. But this was a proof of concept for the boss so it just needed to be up quickly to see if it was something we wanted to go ahead with :) Well, no worries about that then. We're just looking out for your data security. Heaven forbid someone tamper with your database resulting in some poor soul receiving the wrong coffee! ;) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Kesalahan posting?
Every time I post I get this e-mail: Halo [EMAIL PROTECTED], Kami mengirim email ini untuk menyampaikan bahwa grup yang Anda coba hubungi (donkomo) tidak ada atau Anda tidak memiliki izin untuk mengirim pesan ke grup itu. Ada beberapa kemungkinan mengapa hal ini terjadi: [etc.] I have no idea what this means or what language it is in. I don't want to receive an unintelligible (to me) message every time I post. What gives? Thanks. I also think it would be awesome if people didn't set vacation auto-responders on e-mail accounts that are subscribed to the list (I'm looking at you [EMAIL PROTECTED]). If you need to put an away auto-responder, unsubscribe 'til you get back. Thanks. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] PDFlib
Mad Unix wrote: Any help concerning installing PDFLib on PHP5.x APACHE2.x. with RHEL4 http://www.php.net/manual/en/pdf.setup.php -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
