[Xerte] Re: latex/stripslashes/magic quotes etc
Ron Mitchell
ronm at mitchellmedia.co.uk
Mon Jan 21 21:48:36 GMT 2013
>So what's the solution to this? Why is it working ok on the Nottingham
install but not for me and others? Or is it?<
>Different versions of the code base?<
I can't speak for the Nottingham install but on the 3 servers I've been
testing with the XOT code base is the same and there isn't anything in the
xot code overriding the magic_quotes_gpc setting.
In the case of save.php it's updating data.xml and preview.xml with:
if(fwrite($file_handle, stripslashes($_POST['filedata']))!=false){
I don't think it's writing to the db.
If I remove the stripslashes section in save.php and so change the 3
occurrences of the above line to
if(fwrite($file_handle, $_POST['filedata'])!=false){
then the latex works but I'm not sure if that could cause other problems?
From: xerte-bounces at lists.nottingham.ac.uk
[mailto:xerte-bounces at lists.nottingham.ac.uk] On Behalf Of David Goodwin
Sent: 21 January 2013 20:43
To: Xerte discussion list
Subject: [Xerte] Re: latex/stripslashes/magic quotes etc
On 21 Jan 2013, at 17:48, Paul Swanson <Paul.Swanson at harlandfs.com> wrote:
On my php applications, I use the following function before saving any data
to the database:
// function for escaping and trimming form data
function escape_data ($data) {
global $dbc;
if (ini_get ('magic_quotes_gpc')) {
$data = stripslashes ($data);
}
return mysql_real_escape_string (trim ($data), $dbc);
} // end of escape_data() function
Hi,
Random 2p ....
1.I'd avoid using the above - it doesn't protect against e.g.
$sql = "SELECT * FROM users WHERE id = " . escape_data($_GET['id']);
(in this instance, $_GET['id'] needs casting to an int, else injection of
SQL could take place - e.g. $_GET['id'] = '5 union .... "
It checks to see if magic_quotes_gpc is on, and if so, employs the
stripslashes function, since magic_quotes adds slashes. If magic_quotes
isn't on, it skips the stripslashes function. This function ensures that
either configuration is handled.
$dbc in the function is the database connection resource variable.
2. Make sure you've called SET NAMES UTF8 or whatever on that connection ...
assuming you're using unicode...
3. In XOT, use the db_query/db_query_one functions; they'll take in
prepared-statement-esque SQL, which is immune to injection and doesn't
result in you having to care whether $foo has been escaped, double escaped
or not escaped. Just pass the variables you want to embed within the SQL
within an array with ? marks within the actual SQL - like :
$row = db_query_one("SELECT * FROM users WHERE id = ?", array($_GET['id']));
or
$rows = db_query("SELECT * FROM whatever WHERE id = ? AND blah = ?",
array($_GET['id'], $_GET['blah']));
etc etc.
4. Different output formats need different escaping; e.g. the escaping you
need for within javascript (addcslashes) is different to that for html
(htmlentities) and so on. While the 'escapedata' approach may work, it's not
ideal or correct to apply escaping which is appropriate to MySQL on data
which is meant to be output as LaTeX or HTML or whatever.
<snip/>
In previous discussions it's clear that depending on php configuration
previewing and/or publishing was/is stripping slashes to the point that
latex code had all slashes removed and therefore didn't work. There was a
suggestion of using ini_set( 'magic_quotes_gpc', true ); in save.php but
it's not clear if that resolved the issue.
Don't use magic_quotes. They cause PHP to escape everything with
'addslashes()' that comes from user supplied data -e.g database calls,
file_get_contents (probably) and so on. The result of this is that you will
eventually find the data to be a mess - e.g. it\\\\\\\\\'s and so on.
I have an installation (linux) where this is happening so as a test I turned
on magic_quotes_gpc server wide but that hasn't resolved the issue.
Did you check with e.g. phpinfo(); ? Perhaps there is a local setting either
in XOT, or a .htaccess file or elsewhere which is overriding your change?
Perhaps your change didn't take effect.
Also I read that magic quotes has been DEPRECATED
Indeed.
as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
Yes.
So what's the solution to this? Why is it working ok on the Nottingham
install but not for me and others? Or is it?
Different versions of the code base?
David.
Pale Purple Ltd. (Company No: 5580814)
'Business Web Application Development and Training in PHP'
http://www.palepurple.co.uk
Office: 0845 0046746 Mobile: 07792380669
Follow us on Twitter: @PalePurpleLtd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nottingham.ac.uk/pipermail/xerte/attachments/20130121/92400475/attachment.html>
More information about the Xerte
mailing list