php-general Digest 19 Apr 2012 17:30:55 -0000 Issue 7782
Topics (messages 317607 through 317618):
Re: sms class
317607 by: tamouse mailing lists
Re: Email Antispam
317608 by: tamouse mailing lists
317610 by: Bastien
317612 by: Matijn Woudt
317613 by: Ashley Sheridan
Re: tempnam() not working as expected...
317609 by: marco.behnke.biz
317611 by: Matijn Woudt
Variable Question
317614 by: Ron Piggott
317615 by: Stuart Dallas
317616 by: Christoph Boget
317617 by: Shawn McKenzie
SqLite INSERT want not write
317618 by: Silvio Siefke
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 ---
On Tue, Apr 17, 2012 at 2:08 PM, DZvonko Nikolov <dzvo...@yahoo.com> wrote:
> I need a class that sends sms messages to list of numbers.
> I'm quite new to that issue, so I need to know what I need
> more. Thanks in advance.
If this is very low volume, would using email->sms work?
--- End Message ---
--- Begin Message ---
On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <ro...@zeta.org.au> wrote:
> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
>
>>He literally wants the "addresses" visible on the sight? [...]
>
> Yes, they want the addresses visible and clickable on the website. They
> have contact forms, but they also want the email addresses (of their
> scientists and other consultants) available to their clients. And they
> want the addresses to be shielded against harvesting for spam.
Ob/Deobfuscation schemes that use javascript are a partial solution.
Many spam harvesters are smart enough these days to know enough about
decoding email addresses even obfuscated with javascript, with or
without the mailto: scheme. Any that do obfuscation by substituting
html entities for the characters are quite easily cracked. (Just
appearance of a string of html entities is often enough to indicate
there is something there to decode.) There is no 100% solution here.
Coming up with clever ways to obfuscate the address on download, and
deobfuscate it afterwards to display to the user will work for a
while, however, the people writing spam harvesters are just as clever
as we are. If the application is going to end up with email addresses
displayed on the screen, some spam harvester is going to be able to
get them. Even if you come up with a method that will stop them now,
it won't stop them forever.
> As I said, I don't like doing it this way, but the client gets what they
> want after the options have been explained to them.
They need to understand the options, but even more important, the
risks of any solution, and of the concept as a whole. After you've
presented the risks, and the lack of a 100% solution, if they still
want to do something against their own policies, you have to decide if
your liability in giving it to them is going to be a problem.
--- End Message ---
--- Begin Message ---
Bastien Koert
On 2012-04-19, at 1:54 AM, tamouse mailing lists <tamouse.li...@gmail.com>
wrote:
> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <ro...@zeta.org.au> wrote:
>> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
>>
>>> He literally wants the "addresses" visible on the sight? [...]
>>
>> Yes, they want the addresses visible and clickable on the website. They
>> have contact forms, but they also want the email addresses (of their
>> scientists and other consultants) available to their clients. And they
>> want the addresses to be shielded against harvesting for spam.
>
> Ob/Deobfuscation schemes that use javascript are a partial solution.
> Many spam harvesters are smart enough these days to know enough about
> decoding email addresses even obfuscated with javascript, with or
> without the mailto: scheme. Any that do obfuscation by substituting
> html entities for the characters are quite easily cracked. (Just
> appearance of a string of html entities is often enough to indicate
> there is something there to decode.) There is no 100% solution here.
> Coming up with clever ways to obfuscate the address on download, and
> deobfuscate it afterwards to display to the user will work for a
> while, however, the people writing spam harvesters are just as clever
> as we are. If the application is going to end up with email addresses
> displayed on the screen, some spam harvester is going to be able to
> get them. Even if you come up with a method that will stop them now,
> it won't stop them forever.
>
>> As I said, I don't like doing it this way, but the client gets what they
>> want after the options have been explained to them.
>
> They need to understand the options, but even more important, the
> risks of any solution, and of the concept as a whole. After you've
> presented the risks, and the lack of a 100% solution, if they still
> want to do something against their own policies, you have to decide if
> your liability in giving it to them is going to be a problem.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Could this be a place to consider a flash Based solution?
--- End Message ---
--- Begin Message ---
On Thu, Apr 19, 2012 at 1:01 PM, Bastien <phps...@gmail.com> wrote:
>
>
> Bastien Koert
>
> On 2012-04-19, at 1:54 AM, tamouse mailing lists <tamouse.li...@gmail.com>
> wrote:
>
>> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <ro...@zeta.org.au> wrote:
>>> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
>>>
>>>> He literally wants the "addresses" visible on the sight? [...]
>>>
>>> Yes, they want the addresses visible and clickable on the website. They
>>> have contact forms, but they also want the email addresses (of their
>>> scientists and other consultants) available to their clients. And they
>>> want the addresses to be shielded against harvesting for spam.
>>
>> Ob/Deobfuscation schemes that use javascript are a partial solution.
>> Many spam harvesters are smart enough these days to know enough about
>> decoding email addresses even obfuscated with javascript, with or
>> without the mailto: scheme. Any that do obfuscation by substituting
>> html entities for the characters are quite easily cracked. (Just
>> appearance of a string of html entities is often enough to indicate
>> there is something there to decode.) There is no 100% solution here.
>> Coming up with clever ways to obfuscate the address on download, and
>> deobfuscate it afterwards to display to the user will work for a
>> while, however, the people writing spam harvesters are just as clever
>> as we are. If the application is going to end up with email addresses
>> displayed on the screen, some spam harvester is going to be able to
>> get them. Even if you come up with a method that will stop them now,
>> it won't stop them forever.
>>
>>> As I said, I don't like doing it this way, but the client gets what they
>>> want after the options have been explained to them.
>>
>> They need to understand the options, but even more important, the
>> risks of any solution, and of the concept as a whole. After you've
>> presented the risks, and the lack of a 100% solution, if they still
>> want to do something against their own policies, you have to decide if
>> your liability in giving it to them is going to be a problem.
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> Could this be a place to consider a flash Based solution?
Maybe, though that requires clients to have a flash enabled device.
Since iOS devices still don't support flash, that's not a reasonable
option anymore for me.
In the end, there's no real solution for spam bots, I think that a
good spam filter is still the best option. My mail address is at
several places all over the web, though I hardly get any spam in my
inbox (thanks Gmail!).
- Matijn
--- End Message ---
--- Begin Message ---
On Thu, 2012-04-19 at 13:48 +0200, Matijn Woudt wrote:
> On Thu, Apr 19, 2012 at 1:01 PM, Bastien <phps...@gmail.com> wrote:
> >
> >
> > Bastien Koert
> >
> > On 2012-04-19, at 1:54 AM, tamouse mailing lists <tamouse.li...@gmail.com>
> > wrote:
> >
> >> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <ro...@zeta.org.au> wrote:
> >>> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
> >>>
> >>>> He literally wants the "addresses" visible on the sight? [...]
> >>>
> >>> Yes, they want the addresses visible and clickable on the website. They
> >>> have contact forms, but they also want the email addresses (of their
> >>> scientists and other consultants) available to their clients. And they
> >>> want the addresses to be shielded against harvesting for spam.
> >>
> >> Ob/Deobfuscation schemes that use javascript are a partial solution.
> >> Many spam harvesters are smart enough these days to know enough about
> >> decoding email addresses even obfuscated with javascript, with or
> >> without the mailto: scheme. Any that do obfuscation by substituting
> >> html entities for the characters are quite easily cracked. (Just
> >> appearance of a string of html entities is often enough to indicate
> >> there is something there to decode.) There is no 100% solution here.
> >> Coming up with clever ways to obfuscate the address on download, and
> >> deobfuscate it afterwards to display to the user will work for a
> >> while, however, the people writing spam harvesters are just as clever
> >> as we are. If the application is going to end up with email addresses
> >> displayed on the screen, some spam harvester is going to be able to
> >> get them. Even if you come up with a method that will stop them now,
> >> it won't stop them forever.
> >>
> >>> As I said, I don't like doing it this way, but the client gets what they
> >>> want after the options have been explained to them.
> >>
> >> They need to understand the options, but even more important, the
> >> risks of any solution, and of the concept as a whole. After you've
> >> presented the risks, and the lack of a 100% solution, if they still
> >> want to do something against their own policies, you have to decide if
> >> your liability in giving it to them is going to be a problem.
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> > Could this be a place to consider a flash Based solution?
>
> Maybe, though that requires clients to have a flash enabled device.
> Since iOS devices still don't support flash, that's not a reasonable
> option anymore for me.
>
> In the end, there's no real solution for spam bots, I think that a
> good spam filter is still the best option. My mail address is at
> several places all over the web, though I hardly get any spam in my
> inbox (thanks Gmail!).
>
> - Matijn
>
A Flash solution would also be highly innaccessible, which may make it
impossible to use for certain types of company.
Like Matijn, my email address is on a lot of public forums, so I've
resigned myself to not even attempting to obfuscate my email address on
my website. It's like playing a game of whack-a-mole, there is no real
hope of stopping it being harvested once it's online in a readable form.
If a human can read it, what's to stop a human from adding it to some
"marketing" list?
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
tamouse mailing lists <tamouse.li...@gmail.com> hat am 19. April 2012 um
07:10 geschrieben:
> On Mon, Apr 16, 2012 at 3:09 AM, ma...@behnke.biz <ma...@behnke.biz>
wrote:
> >> mkdir($d,777,true); /* make the directory */
> > Try using "mkdir($d, 0777, true);"
>
> Herein, my friends, lies the problem. Silly me, using a DECIMAL number
> (777) instead of an OCTAL number (0777).
:-) well ... you could have written 511 which is 0777 in octal :D
The other way around 777 decimal is 1411 octal. No idea what kinda chmod
mode that is ;-)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3
Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz
Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal
http://www.behnke.biz
--- End Message ---
--- Begin Message ---
On Thu, Apr 19, 2012 at 9:03 AM, ma...@behnke.biz <ma...@behnke.biz> wrote:
>
>
> tamouse mailing lists <tamouse.li...@gmail.com> hat am 19. April 2012 um
> 07:10 geschrieben:
>
>> On Mon, Apr 16, 2012 at 3:09 AM, ma...@behnke.biz <ma...@behnke.biz>
> wrote:
>> >> mkdir($d,777,true); /* make the directory */
>> > Try using "mkdir($d, 0777, true);"
>>
>> Herein, my friends, lies the problem. Silly me, using a DECIMAL number
>> (777) instead of an OCTAL number (0777).
>
> :-) well ... you could have written 511 which is 0777 in octal :D
> The other way around 777 decimal is 1411 octal. No idea what kinda chmod
> mode that is ;-)
That's 0411 with the sticky bit set. When the sticky bit is set on a
directory, files in that directory may only be unlinked or renamed by
root or their owner.
- Matijn
--- End Message ---
--- Begin Message ---
I am trying to assign variables from an array into variables. This is
following a database query. Right now they are in an array:
$row[‘word_1’]
$row[‘word_2’]
$row[‘word_3’]
...
$row[‘word_25’]
I am trying to use this while look to assign them to variables:
$word_1
$word_2
$word_3
...
$word_25
This is the WHILE loop:
$i = 1;
while ( $i <= 25 ) {
${'word_'.$i} = stripslashes( eval ("echo $row['word_$i']") );
++$i;
}
What is confusing me is I don’t know how to represent the array variable.
The specific error message I am receiving is:
Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting
T_STRING or T_VARIABLE or T_NUM_STRING
Can anyone see what I have done wrong and help me correct it? Thank you. Ron
Ron Piggott
www.TheVerseOfTheDay.info
--- End Message ---
--- Begin Message ---
On 19 Apr 2012, at 15:46, Ron Piggott wrote:
> I am trying to assign variables from an array into variables. This is
> following a database query. Right now they are in an array:
>
> $row[‘word_1’]
> $row[‘word_2’]
> $row[‘word_3’]
> ...
> $row[‘word_25’]
Why those indices? Why isn't it just a numerically indexed array?
> I am trying to use this while look to assign them to variables:
> $word_1
> $word_2
> $word_3
> ...
> $word_25
The first question that comes to mind is why the heck you would want to do such
a thing?
> ${'word_'.$i} = stripslashes( eval ("echo $row['word_$i']") );
Eww, nasty. Why the eval? Why not just stripslashes($row['word_'.$i])?
Variable variables have their uses, but this seems to be one of those cases
where you're trying to get the square peg through the triangular hole. Take a
step back and give us some more context.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
> I am trying to use this while look to assign them to variables:
> $word_1
> $word_2
> $word_3
> ...
> $word_25
This should work for you:
http://us3.php.net/manual/en/function.extract.php
thnx,
Christoph
--- End Message ---
--- Begin Message ---
On 04/19/2012 09:55 AM, Christoph Boget wrote:
>> I am trying to use this while look to assign them to variables:
>> $word_1
>> $word_2
>> $word_3
>> ...
>> $word_25
>
> This should work for you:
>
> http://us3.php.net/manual/en/function.extract.php
>
> thnx,
> Christoph
Yes and you can use array_map('stripslashes', $row) prior. However I
would just use the $row array as most people do instead of extracting.
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
Hello,
i have a script which should write articles in a Sqlite 0database. The script
runs without errors, but nothing is written to the database.
The Script: http://nopaste.info/09e68c7e37.html
The db.php: http://nopaste.info/afd4dee47a.html
The Database file has right 777. Has someone an idea? Thank u.
Regards
Silvio
--- End Message ---
