php-general Digest 14 Apr 2009 15:31:27 -0000 Issue 6067
Topics (messages 291458 through 291479):
Re: try - catch is not so clear to me...
291458 by: Lamp Lists
291473 by: Bastien Koert
291476 by: Lamp Lists
Re: https and Credit Cards
291459 by: Paul M Foster
291468 by: Richard Heyes
Re: Logging out of a SSL / https:// site using PHP? (or JS?), Client Side Cache
291460 by: Michael A. Peters
Re: $_GET verses $_POST
291461 by: Ashley Sheridan
291462 by: Michael A. Peters
291463 by: ×× ××× ×× ××
291469 by: Nick Cooper
291474 by: Paul M Foster
291478 by: haliphax
files creation/access dates
291464 by: Tom Sparks
291466 by: Per Jessen
291477 by: haliphax
Re: Generate XHTML (HTML compatible) Code using DOMDocument
291465 by: Peter Ford
bug or expected, mbstring.func_overload not changeable by .htaccess 5.2.8/5.2.9
291467 by: Andre Hübner
Reflection question
291470 by: Pulni4kiya
Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
291471 by: Mikko Koppanen
291475 by: Glen
Re: Nagios Monitoring
291472 by: ×××¨× ×××
Logical next step in learning?
291479 by: Gary
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
________________________________
From: Marc Steinert <[email protected]>
To: Lamp Lists <[email protected]>
Cc: [email protected]
Sent: Monday, April 13, 2009 11:27:08 AM
Subject: Re: [PHP] try - catch is not so clear to me...
Basically try-catch gives you the ability to handle errors outside a class or
method scope, by the calling instance.
This comes in handy, if you are programming in an object orientated way and
thus enables you to seperate error handling from the rest of your functionality.
Means, your methods do only the things, they are meant to do, without bothering
to handling occuring errors.
Hope, that made things clearer.
Greetings from Germany
Marc
Lamp Lists wrote:
>> hi to all!
>>
>> actually, the statement in the Subject line is not 100% correct. I
>> understand the purpose and how it works (at least I think I understand :-))
>> but to me it's so complicated way?
>>
-- http://bithub.net/
Synchronize and share your files over the web for free
My Twitter feed
http://twitter.com/MarcSteinert
Looks like I still didn't get it correctly:
try
{
if (!send_confirmation_email($email, $subject, $content))
{
throw new Exception('Confirmation email is not sent');
}
}
catch (Exception $e)
{
send_email_with_error_to_admin($e, $content);
}
why am I getting both emails? I'm receiving confirmation email and email with
error message - that I'm supposed to get if the first one is not sent for some
reason?!?!?!?
thanks for any help.
-LL
--- End Message ---
--- Begin Message ---
On Mon, Apr 13, 2009 at 11:34 PM, Lamp Lists <[email protected]> wrote:
>
>
>
> ________________________________
> From: Marc Steinert <[email protected]>
> To: Lamp Lists <[email protected]>
> Cc: [email protected]
> Sent: Monday, April 13, 2009 11:27:08 AM
> Subject: Re: [PHP] try - catch is not so clear to me...
>
> Basically try-catch gives you the ability to handle errors outside a class
> or method scope, by the calling instance.
> This comes in handy, if you are programming in an object orientated way and
> thus enables you to seperate error handling from the rest of your
> functionality.
> Means, your methods do only the things, they are meant to do, without
> bothering to handling occuring errors.
> Hope, that made things clearer.
>
> Greetings from Germany
>
> Marc
>
> Lamp Lists wrote:
>
> >> hi to all!
> >>
> >> actually, the statement in the Subject line is not 100% correct. I
> understand the purpose and how it works (at least I think I understand :-))
> but to me it's so complicated way?
> >>
>
>
> -- http://bithub.net/
> Synchronize and share your files over the web for free
>
>
> My Twitter feed
> http://twitter.com/MarcSteinert
>
>
>
>
> Looks like I still didn't get it correctly:
>
> try
> {
> if (!send_confirmation_email($email, $subject, $content))
> {
> throw new Exception('Confirmation email is not sent');
> }
>
> }
> catch (Exception $e)
> {
> send_email_with_error_to_admin($e, $content);
> }
>
> why am I getting both emails? I'm receiving confirmation email and email
> with error message - that I'm supposed to get if the first one is not sent
> for some reason?!?!?!?
>
> thanks for any help.
>
> -LL
>
>
>
what does this function [send_confirmation_email($email, $subject,
$content)] return?
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
________________________________
From: Bastien Koert <[email protected]>
To: Lamp Lists <[email protected]>
Cc: Marc Steinert <[email protected]>; [email protected]
Sent: Tuesday, April 14, 2009 8:11:04 AM
Subject: Re: [PHP] try - catch is not so clear to me...
On Mon, Apr 13, 2009 at 11:34 PM, Lamp Lists <[email protected]> wrote:
________________________________
From: Marc Steinert <[email protected]>
To: Lamp Lists <[email protected]>
Cc: [email protected]
Sent: Monday, April 13, 2009 11:27:08 AM
Subject: Re: [PHP] try - catch is not so clear to me...
Basically try-catch gives you the ability to handle errors outside a class or
method scope, by the calling instance.
This comes in handy, if you are programming in an object orientated way and
thus enables you to seperate error handling from the rest of your functionality.
Means, your methods do only the things, they are meant to do, without bothering
to handling occuring errors.
Hope, that made things clearer.
Greetings from Germany
Marc
Lamp Lists wrote:
>> hi to all!
>>
>> actually, the statement in the Subject line is not 100% correct. I
>> understand the purpose and how it works (at least I think I understand :-))
>> but to me it's so complicated way?
>>
-- http://bithub.net/
Synchronize and share your files over the web for free
My Twitter feed
http://twitter.com/MarcSteinert
Looks like I still didn't get it correctly:
try
{
if (!send_confirmation_email($email, $subject, $content))
{
throw new Exception('Confirmation email is not sent');
}
}
catch (Exception $e)
{
send_email_with_error_to_admin($e, $content);
}
why am I getting both emails? I'm receiving confirmation email and email with
error message - that I'm supposed to get if the first one is not sent for some
reason?!?!?!?
thanks for any help.
-LL
what does this function [send_confirmation_email($email, $subject, $content)]
return?
--
Bastien
Cat, the other other white meat
function send_confirmation_email($to, $subject, $body)
{
$headers = "MIME-Versin: 1.0\n" .
"Content-type: text/plain; charset=ISO-8859-1;
format=flowed\n" .
"Content-Transfer-Encoding: 8bit\n" .
"Reply-To: Contact <[email protected]>\n".
"From: Contact <[email protected]>\n" .
"X-Mailer: PHP" . phpversion();
mail($to, $subject, $body, $headers) or die(mysql_errno());
}
$body is "regular" confirmation text: "Thank you for subscribing. To activate
your account klick on the following link..." etc.
function send_email_with_error_to_admin($e, $content)
{
$error_message = "Caught exception: " . $e->getMessage() . "\n";
$error_message .= "Code : " . $e->getCode()."\n";
$error_message .= "File : " . $e->getFile()."\n";
$error_message .= "Line : " . $e->getLine()."\n";
$to_email = "[email protected]";
$subject = "[Confirmation Error Report] ".$e->getMessage();
$content .=
"\n--------------------------------------------------------------------------------------------------\n\n";
$content .= "Error Report:\n\n".$error_message;
$content .=
"\n--------------------------------------------------------------------------------------------------\n\n";
send_confirmation_email($to_email, $subject, $content);
}
--- End Message ---
--- Begin Message ---
On Mon, Apr 13, 2009 at 10:19:34PM -0500, Skip Evans wrote:
> Hey all,
>
> I've always put any forms that collect credit card information
> behind a secure connection, https, figuring that sending that
> information from the client browser to the server should be
> secure, but I'm having convincing a client that it is necessary.
>
> He instead insists that only the call to the credit card
> processor's server needs to be secure and of course the
> processor supplies the connection there.
>
> But doesn't also the form need to be secure since you're
> sending CC information from that form back to the web site's
> server?
>
> That's what I've always assumed.
>
> I need some opinions on this, and if I'm right I think the
> client will defer to a few more votes.
You're absolutely right, no question, and for exactly the reasons you
give. The path back to the server from the client is unencrypted if you
don't use https, and the credit card information is in the clear when
transmitted.
In fact, if I were a hacker and found out that you were doing this, I'd
make it my business to hijack that connection so I could transparently
capture credit card information. I mean, for a hacker, that's just too
sweet a setup.
Incidentally, if he insists, I'd decline the job. Even if he signed
waiver after waiver to absolve you of responsibility (which I'd make him
sign), he could still go after you later when the consequences hit. Let
some less ethical coder do it the way he wants.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Hi,
> I've always put any forms that collect credit card information behind a
> secure connection, https, figuring that sending that information from the
> client browser to the server should be secure, but I'm having convincing a
> client that it is necessary.
>
> He instead insists that only the call to the credit card processor's server
> needs to be secure and of course the processor supplies the connection
> there.
>
> But doesn't also the form need to be secure since you're sending CC
> information from that form back to the web site's server?
Yes. Any connection to you where your punter supplies CC details
should be secure. If the punters ISP runs a transparent proxy for
example, then these details could be easily captured if not sent over
a secure connection.
--
Richard Heyes
HTML5 Canvas graphing for Firefox, Chrome, Opera and Safari:
http://www.rgraph.net (Updated April 11th)
--- End Message ---
--- Begin Message ---
scubak1w1 wrote:
Hello,
I have a series of web sites which use https:// authentication (using AD
integration to 'check the credentials' as it were) - all seems to be working
well..
I have been Googling et al. for a way to log the user off the site
"fully"...
I can do a series of things on the server side per Dreamweaver's Server
Behaviour / User Authentication | Log Out User, etc - but the client's
browser cache (?) still keeps the credentials, and so ifthey return to the
site (say, with their back button) they can get right back in...
Sounds like you are not properly expiring the session.
The only login credentials that ever should be stored with the client is
a session id.
Expire the session id - and the session ID in their cookie becomes
completely meaningless.
--- End Message ---
--- Begin Message ---
On Mon, 2009-04-13 at 15:47 -0700, Michael A. Peters wrote:
> Daevid Vincent wrote:
> > Just to clarify. Obfuscation is NOT a substitute for security. While I don't
> > disagree with the "when's" here of GET vs POST, this statement is a bit
> > misleading...
> >
> > Any cracker worth his salt can easily install any number of Firefox
> > extensions or unix command line tools and not only view the POST data, but
> > alter it as well. So if you are sending something like a password, don't
> > think that it's "secure" just because Joe Average doesn't see it. If you're
> > not using SSL, then it is sent as plain text like everything else.
> >
> > And don't assume that what you presented on a web page in select boxes and
> > other form elements is the ONLY thing that is going to come back to your
> > server to process. It's trivial to mangle the data. This is what SQL
> > injection is all about.
> > http://en.wikipedia.org/wiki/SQL_injection
> > http://phpsec.org/projects/guide/3.html
> >
> > Daevid.
> > http://daevid.com
>
> It also should be noted that post is not automatically secure against
> csrf attacks. While most csrf attacks are get, they can and do happen
> via post as well.
>
> I agree that passwords need to be sent via SSL.
> Unfortunately most users use the same login and passwords for many
> sites. So even if your site doesn't otherwise need SSL, using SSL for
> login helps protect your users.
>
> For me the biggest advantage of post is the URLs aren't ugly.
> For cases where get with a variable in the URL is useful (IE
> product=BluePhone) - I prefer to handle that via mod_rewrite.
>
> The requests get handled by generic.php and generic.php then looks at
> what the requested URI is to figure out what otherwise would have
> specified by a get.
>
> Just as linkable as ?get=whatever and a lot prettier for the user to
> look at in the url bar.
>
> I think doing it that way also has search engine indexing advantages.
>
I've done a bit of research into that, and can't find any evidence to
suggest that the so-called "friendly URL's" are actually of any benefit
to search engines. Just put a question into Google, and more often than
not, the top few results are from forums, which tend not to use these
friendly URL's. The only reason one might help with SEO is the case
where a site is being redeveloped or re-versioned, and you need to
preserve old page names to retain any ranking the site once had.
Of course, I'm welcome for any evidence to the contrary, so if any of
you have stumbled across links to any of that...
Ash
www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
On Mon, 2009-04-13 at 15:47 -0700, Michael A. Peters wrote:
I think doing it that way also has search engine indexing advantages.
I've done a bit of research into that, and can't find any evidence to
suggest that the so-called "friendly URL's" are actually of any benefit
to search engines.
I haven't done research on it, so I'll take your word for it.
--- End Message ---
--- Begin Message ---
$_REQUEST is "less secure" because it also contains cookie data.
If you manage just to set a cookie, with the name "act" and value "logout",
the user will infinitely log out - You get the point.
On Sun, Apr 12, 2009 at 10:56 PM, Jason Pruim <[email protected]> wrote:
>
> On Apr 12, 2009, at 1:48 PM, Ron Piggott wrote:
>
>
>> Thanks. I got my script updated. Ron
>>
>
> There are a few other thing's that I didn't see mentioned...
>
> The best description of when to use what, is this.. Use POST when you are
> submitting a form for storing info, using GET when you are retrieving from
> the server...
>
> GET can also be bookmarked and shared between computers without a
> problem... So depending on what your app is for that might be a
> consideration.
>
> POST does not display anything in the browser, so as others have said it's
> perfect for login's since that info will never be visible to the user.
>
> as far as REQUEST goes... I personally don't think it's any less secure
> then POST or GET... As long as you do sanitization on the info that is
> appropriate for your app, REQUEST is fine..
>
> Some people prefer to use GET and POST though because then they know where
> the info is coming from...
>
> I think that's everything I wanted to add :)
> Just stuff to think about.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
$_REQUEST is not any less secure then $_POST/$_GET/$_COOKIE, they all
contain raw user data.
The way $_REQUEST is being used in this example is not less secure then
using $_GET. It does open up an exploit but this is not because $_REQUEST is
less secure.
The same exploit exists with $_GET, I could place an image on the page with
src="?act=logout".
$_REQUEST has a place but it should not be used as a direct substitute for
$_GET/POST etc, unless you want the user to be able to have all the options
of posting data to the server.
2009/4/14 דניאל דנון <[email protected]>
> $_REQUEST is "less secure" because it also contains cookie data.
> If you manage just to set a cookie, with the name "act" and value
> "logout",
> the user will infinitely log out - You get the point.
>
> On Sun, Apr 12, 2009 at 10:56 PM, Jason Pruim <[email protected]>
> wrote:
>
> >
> > On Apr 12, 2009, at 1:48 PM, Ron Piggott wrote:
> >
> >
> >> Thanks. I got my script updated. Ron
> >>
> >
> > There are a few other thing's that I didn't see mentioned...
> >
> > The best description of when to use what, is this.. Use POST when you are
> > submitting a form for storing info, using GET when you are retrieving
> from
> > the server...
> >
> > GET can also be bookmarked and shared between computers without a
> > problem... So depending on what your app is for that might be a
> > consideration.
> >
> > POST does not display anything in the browser, so as others have said
> it's
> > perfect for login's since that info will never be visible to the user.
> >
> > as far as REQUEST goes... I personally don't think it's any less secure
> > then POST or GET... As long as you do sanitization on the info that is
> > appropriate for your app, REQUEST is fine..
> >
> > Some people prefer to use GET and POST though because then they know
> where
> > the info is coming from...
> >
> > I think that's everything I wanted to add :)
> > Just stuff to think about.
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
--- End Message ---
--- Begin Message ---
On Tue, Apr 14, 2009 at 07:58:24AM +0100, Ashley Sheridan wrote:
<snip>
> I've done a bit of research into that, and can't find any evidence to
> suggest that the so-called "friendly URL's" are actually of any benefit
> to search engines. Just put a question into Google, and more often than
> not, the top few results are from forums, which tend not to use these
> friendly URL's. The only reason one might help with SEO is the case
> where a site is being redeveloped or re-versioned, and you need to
> preserve old page names to retain any ranking the site once had.
This is a really good point. I've *always* heard/read that ugly URLs
aren't indexed by search engines. But somehow it never occurred to me
that what you're saying about search engine results is true.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Tue, Apr 14, 2009 at 8:40 AM, Paul M Foster <[email protected]> wrote:
> On Tue, Apr 14, 2009 at 07:58:24AM +0100, Ashley Sheridan wrote:
>
> <snip>
>
>> I've done a bit of research into that, and can't find any evidence to
>> suggest that the so-called "friendly URL's" are actually of any benefit
>> to search engines. Just put a question into Google, and more often than
>> not, the top few results are from forums, which tend not to use these
>> friendly URL's. The only reason one might help with SEO is the case
>> where a site is being redeveloped or re-versioned, and you need to
>> preserve old page names to retain any ranking the site once had.
>
> This is a really good point. I've *always* heard/read that ugly URLs
> aren't indexed by search engines. But somehow it never occurred to me
> that what you're saying about search engine results is true.
The URL of a website is just one more field to cram with
"search-engine-friendly" keywords. If your URL isn't
"http://myserver/blog/regex-with-javascript"; it's not going to count
against you NEARLY as much as people seem to believe nowadays. In
fact, you could probably just put the sentence "regex with javascript"
at the top of your HTML source and it would have the same impact.
--
// Todd
--- End Message ---
--- Begin Message ---
how do I get the creation dates on a file?
how do I get the last access date on a file?
tom_a_sparks
Please avoid sending me Word or PowerPoint attachments.
but instead use OpenDocument File Formats or
use OpenOffice
http://en.wikipedia.org/wiki/OpenDocument
http://en.wikipedia.org/wiki/OpenOffice.org
http://www.gnu.org/philosophy/no-word-attachments.html
Enjoy a safer web experience. Upgrade to the new Internet Explorer 8
optimised for Yahoo!7. Get it now.
--- End Message ---
--- Begin Message ---
Tom Sparks wrote:
>
> how do I get the creation dates on a file?
> how do I get the last access date on a file?
>
http://php.net/manual/en/function.stat.php
/Per
--
Per Jessen, Zürich (14.4°C)
--- End Message ---
--- Begin Message ---
On Tue, Apr 14, 2009 at 4:12 AM, Per Jessen <[email protected]> wrote:
> Tom Sparks wrote:
>
>>
>> how do I get the creation dates on a file?
>> how do I get the last access date on a file?
>>
>
> http://php.net/manual/en/function.stat.php
Or, perhaps a bit easier:
http://php.net/filemtime
http://php.net/fileatime
http://php.net/filectime
--
// Todd
--- End Message ---
--- Begin Message ---
Michael Shadle wrote:
> On Mon, Apr 13, 2009 at 2:19 AM, Michael A. Peters <[email protected]> wrote:
>
>> The problem is that validating xhtml does not necessarily render properly in
>> some browsers *cough*IE*cough*
>
> I've never had problems and my work is primarily around IE6 / our
> corporate standards. Hell, even without a script type it still works
> :)
>
>> Would this function work for sending html and solve the utf8 problem?
>>
>> function makeHTML($document) {
>> $buffer = $document->saveHTML();
>> $output = html_entity_decode($buffer,ENT_QUOTES,"UTF-8");
>> return $output;
>> }
>>
>> I'll try it and see what it does.
>
> this was the only workaround I received for the moment, and I was a
> bit afraid it would not process the full range of utf-8; it appeared
> on a quick check to work but I wanted to run it on our entire database
> and then ask the native geo folks to examine it for correctness.
I find that IE7 (at least) is pretty reliable as long as I use strict XHTML and
send a DOCTYPE header to that effect at the top - that seems to trigger a
standard-compliant mode in IE7.
At least then I only have to worry about the JavaScript incompatibilities, and
the table model, and the event model, and ....
--
Peter Ford phone: 01580 893333
Developer fax: 01580 893399
Justcroft International Ltd., Staplehurst, Kent
--- End Message ---
--- Begin Message ---
Hello,
following in my .htaccess works with php 5.2.6 (mod_php)
php_value mbstring.func_overload 2
Seems that since (5.2.7?) 5.2.8/5.2.9 this value is not any more accepted by
php in .htaccess.
mbstring.func_overload should be changeable by PHP_INI_PERDIR which includes
.htaccess
Other values are changeable by .htaccess so it should not be a general
problem on my side.
Please someone could check this?
Thanks,
Andre
--- End Message ---
--- Begin Message ---
Hi, everyone!
I need to do the following:
Let's say I have this class:
class A {
public function b(array $c, $d = 6) { ... }
}
I need to get this in runtime:
"public function b(array $c, $d = 6)"
What's the best way to do it?
(I don't quite like the idea of reading the file in which the class is
defined and it might not always work...)
--- End Message ---
--- Begin Message ---
On Tue, Apr 14, 2009 at 1:26 PM, Glen <[email protected]> wrote:
> I didn't say PHP tags were valid XML. I said short_open_tag conflicts
> with <?xml and other PIs.
>
> <% is not valid XML either, but it doesn't conflict with processing
> instructions.
>
> Glen.
Hello Glen,
posting to mailing-lists is not a speed race so think about your answer
before sending it. There should be no need to send four emails in a row as
you can easily answer multiple persons / arguments in a single post. This
discussion belongs to internals list anymore, so please move it to
php-general mailing list.
CCing the correct list in this mail.
--
Mikko Koppanen
--- End Message ---
--- Begin Message ---
Mikko,
I'm not in a speed race. All my answers are well-thought out. I sent
separate e-mails because mailing list discussions are threaded*, and I
was responding to different people regarding different things. Who
should I reply to if I want to respond to more than one person?
I apologize if I've caused anyone any inconvenience.
Glen.
* http://aspn.activestate.com/ASPN/Mail/Message/php-dev/3710073
Mikko Koppanen wrote:
> On Tue, Apr 14, 2009 at 1:26 PM, Glen <[email protected]
> <mailto:[email protected]>> wrote:
>
> I didn't say PHP tags were valid XML. I said short_open_tag conflicts
> with <?xml and other PIs.
>
> <% is not valid XML either, but it doesn't conflict with processing
> instructions.
>
> Glen.
>
>
>
> Hello Glen,
>
> posting to mailing-lists is not a speed race so think about your
> answer before sending it. There should be no need to send four emails
> in a row as you can easily answer multiple persons / arguments in a
> single post. This discussion belongs to internals list anymore, so
> please move it to php-general mailing list.
>
> CCing the correct list in this mail.
>
> --
> Mikko Koppanen
--- End Message ---
--- Begin Message ---
Normally, I would write the plugin in perl but the general rule is to
return the right exit code to nagios, meaning, the plugin performs a
test and exits with a code from 0-3 which indicates to nagios of the
result of the test, it is also possible to also return a test message
along wit hthe code.
for a more information you may look here:
http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN78
Liran Cohen
CEO
+972-54-5617070
בניית אתרים <http://www.rct.co.il>
מוצרי פרסום <http://www.icon-a.com>
ציטוט Waynn Lue:
Hey guys,
I'm looking to write a nagios plugin that essentially monitors whether or
not a database query returns a value > 0 at any given point. I was hoping
to write this in PHP, but I haven't found too many examples of Nagios
plugins in PHP (
http://www.barryodonovan.com/index.php/2007/11/02/asterisk-pri-nagios is the
best one I've found so far). Just wondering if anyone has any experience
writing them?
Waynn
--- End Message ---
--- Begin Message ---
I am nearing completion of Head First PHP & MySQL, which is a beginners
book. Does anyone have a next step in a choice of a book to progress my
studies?
I have been watching the board,starting to understand some of the
questions,and have been following some of the responses,in partiuclar to the
PHP site, but would like to have a next step book to work on.
Any suggestions?
Gary
BTW, I really enjoyed the Head First method of teaching, making learning
such a complicated subject as coding a little easier.
--- End Message ---
