php-general Digest 9 Jul 2010 10:12:24 -0000 Issue 6837
Topics (messages 306762 through 306782):
Re: Simple XML - problem with errors
306762 by: Marc Guay
306763 by: Gary .
306764 by: Richard Quadling
306765 by: Marc Guay
306766 by: Nisse Engström
306774 by: Gary .
306775 by: Gary .
306776 by: Gary .
306779 by: Richard Quadling
Login using just cookies, bad idea?
306767 by: Michael Calkins
306770 by: Ashley Sheridan
306778 by: Adam Richardson
Re: Setting up a XDebug debugging environment for PHP / WAMP / Eclipse PDT
306768 by: Adam Richardson
MSSQL failing.
306769 by: Paul Halliday
306773 by: Tommy Pham
306777 by: Andrew Ballard
306782 by: Paul Halliday
Re: Date Test...
306771 by: Ashley Sheridan
306772 by: Don Wieland
validating form input
306780 by: David Mehler
306781 by: Michael Shadle
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
> I wonder what the difference is between doing "new
> SimpleXMLElement" and calling simplexml_load_string which results in the
> libxml_use_internal_errors call being ineffective. Odd.
The documentation for "Dealing with XML errors" only mentions
simplexml_load_string() and this comment
http://ca3.php.net/manual/en/simplexml.examples-basic.php#93263 shows
that you're not the first person to run into this.
Marc
--- End Message ---
--- Begin Message ---
Okay. At least one of the problems with this so called HTML seems to
be that the body tag looks like
<BODY vlink=#ffffff ...>
and xml_parse complains that "> required" on that line (i.e. it is
claiming it can't find the end of the tag!).
I'm guessing that those attributes "must" be quoted in XML and
"should" be in HTML (but patently aren't)? Is there any way to get
xml_parse to ignore that? My element_handler functions never even get
a chance to see that line.
Regex to insert quotes or remove the attributes entirely, perhaps?
*gulp* I hope there's a better way than that.
--- End Message ---
--- Begin Message ---
On 8 July 2010 16:15, Gary . <php-gene...@garydjones.name> wrote:
> Okay. At least one of the problems with this so called HTML seems to
> be that the body tag looks like
> <BODY vlink=#ffffff ...>
> and xml_parse complains that "> required" on that line (i.e. it is
> claiming it can't find the end of the tag!).
>
> I'm guessing that those attributes "must" be quoted in XML and
> "should" be in HTML (but patently aren't)? Is there any way to get
> xml_parse to ignore that? My element_handler functions never even get
> a chance to see that line.
>
> Regex to insert quotes or remove the attributes entirely, perhaps?
> *gulp* I hope there's a better way than that.
So. Essentially, you want to parse some plain text which may or may
not be well formed XML.
In short ... good luck.
How badly formed is the file going to be?
If it is things like missing ", then this could be managed with regex.
Essentially you are going to have to do the clean up that Tidy could
do for you.
--- End Message ---
--- Begin Message ---
> And yes, I'd rather use DOM, but I can't.
Could you use this: http://simplehtmldom.sourceforge.net/?
--- End Message ---
--- Begin Message ---
On Thu, 8 Jul 2010 17:15:02 +0200, "Gary ." wrote:
> Okay. At least one of the problems with this so called HTML seems to
> be that the body tag looks like
> <BODY vlink=#ffffff ...>
> and xml_parse complains that "> required" on that line (i.e. it is
> claiming it can't find the end of the tag!).
>
> I'm guessing that those attributes "must" be quoted in XML and
> "should" be in HTML (but patently aren't)?
For that attribute value, it's a "must" in both cases.
And for strict versions of (X)HTML, the attribute does
not exist at all.
/Nisse
--- End Message ---
--- Begin Message ---
On 7/8/10, Richard Quadling wrote:
> On 8 July 2010 16:15, Gary wrote:
>> Okay. At least one of the problems with this so called HTML seems to
>> be that the body tag looks like
>> <BODY vlink=#ffffff ...>
>> and xml_parse complains that "> required" on that line (i.e. it is
>> claiming it can't find the end of the tag!).
>>
>> I'm guessing that those attributes "must" be quoted in XML and
>> "should" be in HTML (but patently aren't)? Is there any way to get
>> xml_parse to ignore that? My element_handler functions never even get
>> a chance to see that line.
>>
>> Regex to insert quotes or remove the attributes entirely, perhaps?
>> *gulp* I hope there's a better way than that.
>
> So. Essentially, you want to parse some plain text which may or may
> not be well formed XML.
No. I don't *want* to.... And it isn't plain text, it's just sh*t html
(no doctype, missing closing tags in some cases, etc. It's an
absolute mess). Browsers are pretty good at handling it. XML
parsers... less so.
> How badly formed is the file going to be?
It's not a file. It comes from an embedded web server on a device. I
could ask them to change it. I can hear the laughter already.
> If it is things like missing ", then this could be managed with regex.
> Essentially you are going to have to do the clean up that Tidy could
> do for you.
Yeah :(
--- End Message ---
--- Begin Message ---
On 7/8/10, Marc Guay wrote:
>> And yes, I'd rather use DOM, but I can't.
>
> Could you use this: http://simplehtmldom.sourceforge.net/?
Interesting.
Although I can't use DOM or Tidy (because they're normally built in,
but TPTB decided to recompile PHP and exclude them, and I am not
allowed to recompile it with them in), that's external so might be a
possibility.
Thanks.
--- End Message ---
--- Begin Message ---
On 7/8/10, Nisse Engström wrote:
> On Thu, 8 Jul 2010 17:15:02 +0200, "Gary ." wrote:
>> I'm guessing that those attributes "must" be quoted in XML and
>> "should" be in HTML (but patently aren't)?
>
> For that attribute value, it's a "must" in both cases.
Okay. Please tell L******! :)
--- End Message ---
--- Begin Message ---
On 8 July 2010 18:55, Gary . <php-gene...@garydjones.name> wrote:
> On 7/8/10, Marc Guay wrote:
>>> And yes, I'd rather use DOM, but I can't.
>>
>> Could you use this: http://simplehtmldom.sourceforge.net/?
>
> Interesting.
>
> Although I can't use DOM or Tidy (because they're normally built in,
> but TPTB decided to recompile PHP and exclude them, and I am not
> allowed to recompile it with them in), that's external so might be a
> possibility.
>
> Thanks.
If it were windows, then the Tidy extension is loadable via php.ini.
You could ask TPTB why they've removed the only tool that can read
this sh*t with any success?
Make the case for it. If they still say no, then tell them that the
sh*t is NOT XML and therefore the XML tools won't read it.
--- End Message ---
--- Begin Message ---
I right now have a complete user login and registration system however it uses
cookies when you login to store information. Is this a bad thing?$_COOKIE vs
$_SESSION for login systems
From,Michael calkinsmichaelcalk...@live.com425-239-9952
_________________________________________________________________
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
--- End Message ---
--- Begin Message ---
On Thu, 2010-07-08 at 09:53 -0700, Michael Calkins wrote:
> I right now have a complete user login and registration system however it
> uses cookies when you login to store information. Is this a bad
> thing?$_COOKIE vs $_SESSION for login systems
>
> From,Michael calkinsmichaelcalk...@live.com425-239-9952
>
>
> _________________________________________________________________
> The New Busy is not the too busy. Combine all your e-mail accounts with
> Hotmail.
> http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
VERY bad idea! :p
Basically, cookies should only be used to store general non-personal
information. Sessions are for anything that you want to keep out of
prying eyes. The reason being is that cookies are just plain text files
on the client machine, and can effectively be read by another program or
person very easily.
Sessions make use of cookies to store the session_id whilst a user is
logged in, but you should destroy the session after you no-longer need
it to remove the chance of someone getting hold of it and spoofing a
request to your server. This can be done by destroying the session when
a user logs out and setting a default timeout on a session.
Sessions are easier to use I've found than cookies. You can add
information to the session and read it right back without need the
clients browser to make a new request to your server with the updated
cookie in the header. You can store far more information in a session
(exactly how much more depends on your server setup obviously) and in a
much more logical manner than a cookie.
This is not to say that cookies don't have their uses, but I think for a
login system they introduce potential security issues which can be
exploited.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Thu, Jul 8, 2010 at 1:00 PM, Ashley Sheridan
<a...@ashleysheridan.co.uk>wrote:
> On Thu, 2010-07-08 at 09:53 -0700, Michael Calkins wrote:
>
> > I right now have a complete user login and registration system however it
> uses cookies when you login to store information. Is this a bad
> thing?$_COOKIE vs $_SESSION for login systems
> >
> > From,Michael calkinsmichaelcalk...@live.com425-239-9952
> >
> >
> > _________________________________________________________________
> > The New Busy is not the too busy. Combine all your e-mail accounts with
> Hotmail.
> >
> http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
>
>
> VERY bad idea! :p
>
> Basically, cookies should only be used to store general non-personal
> information. Sessions are for anything that you want to keep out of
> prying eyes. The reason being is that cookies are just plain text files
> on the client machine, and can effectively be read by another program or
> person very easily.
>
> Sessions make use of cookies to store the session_id whilst a user is
> logged in, but you should destroy the session after you no-longer need
> it to remove the chance of someone getting hold of it and spoofing a
> request to your server. This can be done by destroying the session when
> a user logs out and setting a default timeout on a session.
>
> Sessions are easier to use I've found than cookies. You can add
> information to the session and read it right back without need the
> clients browser to make a new request to your server with the updated
> cookie in the header. You can store far more information in a session
> (exactly how much more depends on your server setup obviously) and in a
> much more logical manner than a cookie.
>
> This is not to say that cookies don't have their uses, but I think for a
> login system they introduce potential security issues which can be
> exploited.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
Hi Michael,
The short answer is that it depends.
Cookies are not inherently bad. Cookies are simply another piece of text
that's sent to and fro from client to server (via "Set-Cookie: name= value"
and "Cookie: name=value" exchanges), and this particular piece of text has a
special storage mechanism integrated into most web browsers. Since it's
inception, cookie support has improved significantly on browsers, as the
security policies now in place provide much more security than those first
implemented in the olden days. Today, cookies are a valuable tool used to
facilitate the vast majority of website login mechanisms.
PHP uses cookies to track sessions of web visitors (the cookie stores the
corresponding PHPSESSID), and these sessions are often used to handle auth
checks. That is, unless you've set your PHP environment up to propagate the
session id through the url, which is not usually wise as it's quite easy to
expose the PHPSESSID in server logs as through the referrer header:
http://php.net/manual/en/session.security.php
ASP.Net uses cookies to handle the provide the forms-based auth mechanism,
storing limited session information directly within the cookie itself:
http://msdn.microsoft.com/en-us/library/ff647070.aspx#pagexplained0002_aspnetforms
I right now have a complete user login and registration system however it
> uses cookies when you login to store information.
Now, the questions I'd have for you are:
- Are the cookies merely storing the auth tokens or is other information
being stored?
- If other information is being stored, what type of info is it, how
secure does it have to be, and how many bytes of data is it.
Whatever scheme you're using, if you're exchanging the cookie over a
non-secure channel (i.e., not using HTTPS), you're application is vulnerable
to session hijacking:
http://en.wikipedia.org/wiki/Session_hijacking
I have stored limited amounts of information in the cookie (e.g., default
stylesheet info, user first name, etc.), and when I wanted to protect the
information, I signed and encrypted it. Because of the nature of a cookie,
you'd have to guard against replay attacks even if the information is
encrypted:
http://en.wikipedia.org/wiki/Replay_attack
In summary, a cookie is merely a tool for persisting data on the client. It
can facilitate great security, but it's contribution (or detriment) to the
security of your application depends on how it's used.
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On Thu, Jul 8, 2010 at 6:40 AM, David Négrier <
d.negr...@thecodingmachine.com> wrote:
> Hi list,
>
> After struggling a bit to set-up a debug environment in PHP, I decided to
> write a complete tutorial to explain how to set-up XDebug in a WAMP /
> Eclipse PDT environment.
>
> Everything was already available on the web but was squattered on several
> different sites.
> I've tried to write a simple and concise article, and I hope it will
> benefit the community. It is so confortable to use a break-point in PHP
> instead of debugging with var_dump!
>
> Here is the link to the article:
>
>
> http://blog.thecodingmachine.com/content/setting-xdebug-debugging-environment-php-wamp-eclipse-pdt
>
> Enjoy,
> David.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Thanks for sharing, David. That's a nice compilation of information into
one easy-to-read post.
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
Is there something that needs to be tweaked or added to get this to
work? I am trying to connect to server 2008 w/ MS SQL 2008. I can see
the connections fail in the servers event logs if I take away \domain
from \domain\username (mixed auth is turned off) so the communication
is somewhat working.
What am I missing?
Settings are as follows:
MSSQL Support enabled
Active Persistent Links 0
Active Links 0
Library version FreeTDS
Directive Local Value Master Value
mssql.allow_persistent On On
mssql.batchsize 0 0
mssql.charset no value no value
mssql.compatability_mode Off Off
mssql.connect_timeout 5 5
mssql.datetimeconvert On On
mssql.max_links Unlimited Unlimited
mssql.max_persistent Unlimited Unlimited
mssql.max_procs Unlimited Unlimited
mssql.min_error_severity 10 10
mssql.min_message_severity 10 10
mssql.secure_connection Off Off
mssql.textlimit Server default Server default
mssql.textsize Server default Server default
mssql.timeout 60 60
Thanks
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Paul Halliday [mailto:paul.halli...@gmail.com]
> Sent: Thursday, July 08, 2010 10:01 AM
> To: php-gene...@lists.php.net
> Subject: [PHP] MSSQL failing.
>
> Is there something that needs to be tweaked or added to get this to work?
I
> am trying to connect to server 2008 w/ MS SQL 2008. I can see the
> connections fail in the servers event logs if I take away \domain from
> \domain\username (mixed auth is turned off) so the communication is
> somewhat working.
>
> What am I missing?
>
> Settings are as follows:
>
> MSSQL Support enabled
> Active Persistent Links 0
> Active Links 0
> Library version FreeTDS
>
> Directive Local Value Master Value
> mssql.allow_persistent On On
> mssql.batchsize 0 0
> mssql.charset no value no value
> mssql.compatability_mode Off Off
> mssql.connect_timeout 5 5
> mssql.datetimeconvert On On
> mssql.max_links Unlimited Unlimited
> mssql.max_persistent Unlimited Unlimited
> mssql.max_procs Unlimited Unlimited
> mssql.min_error_severity 10 10
> mssql.min_message_severity 10 10
> mssql.secure_connection Off Off
> mssql.textlimit Server default Server default
> mssql.textsize Server default Server default
> mssql.timeout 60 60
>
> Thanks
>
What driver are you using? MS SQL Server driver for PHP?
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ccdf
728b-1ea0-48a8-a84a-5052214caad9
Regards,
Tommy
--- End Message ---
--- Begin Message ---
On Thu, Jul 8, 2010 at 1:01 PM, Paul Halliday <paul.halli...@gmail.com> wrote:
> Is there something that needs to be tweaked or added to get this to
> work? I am trying to connect to server 2008 w/ MS SQL 2008. I can see
> the connections fail in the servers event logs if I take away \domain
> from \domain\username (mixed auth is turned off) so the communication
> is somewhat working.
>
> What am I missing?
>
Is the slash before the domain name above just a typo in your e-mail?
It took a while to get mssql configured to where I could test it here
since we're using Microsoft's SQL Server Driver for PHP (if you are
running PHP under Windows, I'd strongly recommend this over the old
mssql library anyway), but this worked:
<?php
$hostname = 'hostname:1433';
$username = 'DOMAIN\Username';
$password = 'password';
$conn = mssql_connect($hostname, $username, $password) or die('Unable
to connect');
var_dump($conn);
?>
Andrew
--- End Message ---
--- Begin Message ---
>>
>> What am I missing?
>>
>
> Is the slash before the domain name above just a typo in your e-mail?
> It took a while to get mssql configured to where I could test it here
> since we're using Microsoft's SQL Server Driver for PHP (if you are
> running PHP under Windows, I'd strongly recommend this over the old
> mssql library anyway), but this worked:
>
> <?php
>
> $hostname = 'hostname:1433';
>
> $username = 'DOMAIN\Username';
> $password = 'password';
>
> $conn = mssql_connect($hostname, $username, $password) or die('Unable
> to connect');
>
> var_dump($conn);
>
> ?>
>
> Andrew
>
It was a typo :) The installation is running on FreeBSD. I am looking
at TDS right now as a possible cause.
--- End Message ---
--- Begin Message ---
On Wed, 2010-07-07 at 13:28 -0700, Don Wieland wrote:
> Hello all,
>
> I am processing an array to build an INSERT string in PHP. The code
> below I build an a separate array for the TARGET fields and the VALUES.
>
> I am trying to trap for a NULL ENTRY in a Date Input Field. Date
> fields are identified with: $ffield['s']=='/'
>
> I tried to add the "&& !empty($fval)" to the test but it is giving my
> an unexpected results. In my case, I have a Data of Birth field that
> keeps populating in the future: So 1941-06-16 inserts in the DB as
> 2041-06-16.
>
> foreach($form_fields as $ffield){
> $fval = is_array($ffield['f'])?joinFields($ffield['s'],
> $ffield['f']):$_POST[$ffield['f']];
> $query_values[] =
> "'".mysql_real_escape_string($ffield['s']=='/'
> && !empty($fval) ?date('y-m-d',strtotime($fval)):$fval)."'";
> }
>
> Will anyone point out the problem with this CODE?
>
> Don Wieland
>
I can't see anything immediately wrong, but the tertiary operators here
mixed in with the mysql_ function and string concatenation don't make
for easy reading! Maybe add some brackets to partition things off a bit
to make the code easier on the eye. :p
Have you tried echo'ing out the queries to see if they actually look
well-formed? One place it could fall over is if the values you're using
in it aren't well formed.
Lastly, you're using a $_POST field directly in your query if the first
tertiary if/else fails. You should at the very least validate it to make
sure it's in the form you expect, which has to at least be something
that can be parsed and processed by strtotime() which you're using in
your example.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Jul 8, 2010, at 10:09 AM, Ashley Sheridan wrote:
thanks Ash,
I figure it out. I was not entering the full year.
date('y-m-d',strtotime($fval))
needed to be
date('o-m-d',strtotime($fval))
Duh ;-)
Thanks,
Don
On Wed, 2010-07-07 at 13:28 -0700, Don Wieland wrote:
Hello all,
I am processing an array to build an INSERT string in PHP. The code
below I build an a separate array for the TARGET fields and the
VALUES.
I am trying to trap for a NULL ENTRY in a Date Input Field. Date
fields are identified with: $ffield['s']=='/'
I tried to add the "&& !empty($fval)" to the test but it is giving my
an unexpected results. In my case, I have a Data of Birth field that
keeps populating in the future: So 1941-06-16 inserts in the DB as
2041-06-16.
foreach($form_fields as $ffield){
$fval = is_array($ffield['f'])?joinFields($ffield['s'],
$ffield['f']):$_POST[$ffield['f']];
$query_values[] =
"'".mysql_real_escape_string($ffield['s']=='/'
&& !empty($fval) ?date('y-m-d',strtotime($fval)):$fval)."'";
}
Will anyone point out the problem with this CODE?
Don Wieland
I can't see anything immediately wrong, but the tertiary operators
here mixed in with the mysql_ function and string concatenation
don't make for easy reading! Maybe add some brackets to partition
things off a bit to make the code easier on the eye. :p
Have you tried echo'ing out the queries to see if they actually look
well-formed? One place it could fall over is if the values you're
using in it aren't well formed.
Lastly, you're using a $_POST field directly in your query if the
first tertiary if/else fails. You should at the very least validate
it to make sure it's in the form you expect, which has to at least
be something that can be parsed and processed by strtotime() which
you're using in your example.
Thanks,
Ash
http://www.ashleysheridan.co.uk
Don Wieland
D W D a t a C o n c e p t s
~~~~~~~~~~~~~~~~~~~~~~~~~
d...@dwdataconcepts.com
Direct Line - (949) 305-2771
Integrated data solutions to fit your business needs.
Need assistance in dialing in your FileMaker solution? Check out our
Developer Support Plan at:
http://www.dwdataconcepts.com/DevSup.html
Appointment 1.0v9 - Powerful Appointment Scheduling for FileMaker Pro
9 or higher
http://www.appointment10.com
For a quick overview -
http://www.appointment10.com/Appt10_Promo/Overview.html
--- End Message ---
--- Begin Message ---
Hello,
Got a form that takes in data to enter in to a database. I want to
make it as secure and as invulnerable to sql injection and other
attacks as possible. I'm wondering if mysqli_real_escape_string or
stripslashes should be used or if the former does the latter. For
example, I have a name variable:
$name = mysqli_real_escape_string($DatabaseLink, trim($_POST['name']));
or should I do:
$name = stripslashes(mysqli_real_escape_string($dbc, trim($_POST['name'])));
Thanks.
Dave.
--- End Message ---
--- Begin Message ---
On Jul 8, 2010, at 12:38 PM, David Mehler <dave.meh...@gmail.com> wrote:
> Hello,
> Got a form that takes in data to enter in to a database. I want to
> make it as secure and as invulnerable to sql injection and other
> attacks as possible. I'm wondering if mysqli_real_escape_string or
> stripslashes should be used or if the former does the latter. For
> example, I have a name variable:
>
> $name = mysqli_real_escape_string($DatabaseLink, trim($_POST['name']));
This would work. Escaping the string should be all you need. As long as you use
single quotes for wrapping the column values. Double quotes not sure but
shouldn't be using those anyway.
>
> or should I do:
>
> $name = stripslashes(mysqli_real_escape_string($dbc, trim($_POST['name'])));
No... You'd be adding slashes and then removing them here :p
>
> Thanks.
> Dave.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
