php-general Digest 18 Feb 2012 05:16:21 -0000 Issue 7694
Topics (messages 316710 through 316723):
Re: basic captcha
316710 by: Donovan Brooke
316711 by: Donovan Brooke
316712 by: Donovan Brooke
316719 by: Geoff Shang
Re: html_entity_decode is trying to kill me
316713 by: Matijn Woudt
316714 by: Marc Guay
316715 by: Marc Guay
316716 by: HallMarc Websites
Re: Do an LDAP Password Modify Extended Operation?
316717 by: Mike Mackintosh
316718 by: Kirk.Johnson.zootweb.com
316722 by: Mike Mackintosh
Wrong POSTFIELDS Posted
316720 by: Brian Smither
316721 by: Marco Behnke
Re: ASP to PHP
316723 by: Brian Smither
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 ---
Savetheinternet wrote:
[snip]
There are plenty of free PHP captcha scripts out there. Just google
"captcha PHP". Securimage (phpcaptcha.org) looks relatively okay.
Thanks,
Michael
Hi Michael, this looked promising.. however, requires some GD support it
appears I don't have.. here is the results of their test file:
--------------------
GD Support: Yes!
GD Version: bundled (2.0.34 compatible)
imageftbbox function: No
The imageftbbox() function is not included with your gd build. This
function is required.
TTF Support (FreeType): No
No FreeType support. You cannot use Securimage 3.0, but can use 2.0
with gd fonts.
JPEG Support: Yes!
PNG Support: Yes!
GIF Read Support: Yes!
GIF Create Support: Yes!
-------------------
Will keep looking I guess.
Thx.
Donovan
--
D Brooke
--- End Message ---
--- Begin Message ---
Donovan Brooke wrote:
[snip]
Hi Michael, this looked promising.. however, requires some GD support it
appears I don't have.[snip]
Hi, well, just did the test on the live server and it *does* support it
there.. so I guess I use it.. just won't work in the development enviro.
Thanks for the suggestion!
Donovan
--
D Brooke
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
[snip]
Well, if the answer doesn't matter, another could just pick anything and run
with it couldn't they?
Thanks,
Ash
For the favorite color thing? The idea would be to require one (but not
all) of the word options in the list (so answer does matter)... most
bots would not be able to deal with that.. however, like I said, not
fool proof (and not recommended for sensitive purposes). ;-)
Donovan
--
D Brooke
--- End Message ---
--- Begin Message ---
On Fri, 17 Feb 2012, Ashley Sheridan wrote:
I would avoid making a user type in something they see in a picture, as
you've just succeeded in pissing off a bunch of blind people.
Thank you! Glad someone pointed this out so I didn't have to.
And if you use a system like Recaptcha which has an audio option, you've
still locked out deafblind users.
Also, avoid relying on javascript. It can be turned off, disabled,
blocked and sometimes isn't available at all, such as with some
speech/Braille browsers.
Or lynx. Yes I'm a blind person, but even a person who isn't may want to
use it quickly from a shell to get something done.
One popular route is to ask a question that only a human could answer. I
use this method on the contact page of my site. I just ask a question
such as
Multiply the number of heads a person has by the number of legs on 2 dogs.
It's easy for a human, but requires context, something a bot can't do
effectively.
Since the person was looking for a ready-made solution, I'd like to
recommend TextCaptcha.com. It claims to have 180,243,205 easy questions,
and even has an article on ways to avoid needing a CAPTCHA in the first
place.
I once (and only once) struck a test like this on a New Zealand government
website. I nearly died of shock. And I was able to use it with lynx
with no problems at all.
Geoff.
--- End Message ---
--- Begin Message ---
On Fri, Feb 17, 2012 at 5:00 PM, Marc Guay <marc.g...@gmail.com> wrote:
> Hi,
>
> So I decided to give one of those PHP math classes a go and have come
> across a joyful character encoding problem. He's the deal:
>
> $rule = "1 < 2";
> $rule = html_entity_decode($rule, ENT_QUOTES, 'UTF-8');
> echo $rule;
>
> And the result is still "1 < 2". I've tried different combinations
> of character encodings and quotings, to no avail. Any ideas of where
> I should look for the culprit?
>
> Marc
>
This piece of code is working perfectly fine on my Ubuntu PHP 5.3.6.
(I get 1 < 2 ). Can you post some information about your system, eg
PHP version, Apache version, Operating System, OS language?
- Matijn
--- End Message ---
--- Begin Message ---
It actually works for me as well if I run it in the browser. The
structure of the app is a bit strange, though, so debugging character
encoding issues is quite difficult. The code is being run by Code
Igniter in the backend and the response passed via JSON to a ExtJS 4
frontend, so what I'm looking at to debug is the server's response in
the browser console. What I can say is that I decode the string and
pass it immediately afterwards to the EvalMath class that was
suggested earlier, it complains that there's illegal characters
"<", so obviously it's the server that isn't operating as
expected... but why?
PHP/5.3.2-1ubuntu4.14
Apache/2.2.14
--- End Message ---
--- Begin Message ---
Ugh. The problem is that the EvalMath class doesn't death with
comparisons between numbers, it only performs calculations. Barking
up the wrong tree for 2 hours is fun on a Friday!
--- End Message ---
--- Begin Message ---
> Ugh. The problem is that the EvalMath class doesn't death with
comparisons
> between numbers, it only performs calculations. Barking up the wrong tree
> for 2 hours is fun on a Friday!
>
Sorry, I just noticed death; seems your fingers contracted deal with into
death. Interersting...
--- End Message ---
--- Begin Message ---
On Feb 17, 2012, at 10:57, kirk.john...@zootweb.com wrote:
> Is it possible to do an LDAP Password Modify Extended Operation, as
> specified in RFC 3062? The password hashing scheme in the LDAP directory I
> am working with may change periodically, so it is my understanding that I
> can't hash a new password according to a specific scheme, e.g., {SHA}, on
> my side. Instead, I should use an Extended Operation and let the directory
> do the hashing. Is that correct? The help page for ldap_set_option
> suggests that it might be possible, but I sure can't find any example code
> anywhere.
>
> TIA
>
> Kirk
I have an example of this on my lab box at home. I noticed issues depending on
if the requesting application was Linux or windows due to the different Linux
LDAP libraries.
When I get home I'll forward you the example of what I have so far
--- End Message ---
--- Begin Message ---
Mike Mackintosh <mike.mackint...@angrystatic.com> wrote on 02/17/2012
12:36:06 PM:
> On Feb 17, 2012, at 10:57, kirk.john...@zootweb.com wrote:
>
> > Is it possible to do an LDAP Password Modify Extended Operation, as
> > specified in RFC 3062? The password hashing scheme in the LDAP
directory I
> > am working with may change periodically, so it is my understanding
that I
> > can't hash a new password according to a specific scheme, e.g., {SHA},
on
> > my side. Instead, I should use an Extended Operation and let the
directory
> > do the hashing. Is that correct? The help page for ldap_set_option
> > suggests that it might be possible, but I sure can't find any example
code
> > anywhere.
> >
> > TIA
> >
> > Kirk
>
> I have an example of this on my lab box at home. I noticed issues
> depending on if the requesting application was Linux or windows due
> to the different Linux LDAP libraries.
>
> When I get home I'll forward you the example of what I have so far
Woohoo! Extended Operation doesn't seem to be a practice that is in
wide-spread use. Looking forward to what you've come up with. Thanks.
--- End Message ---
--- Begin Message ---
On Feb 17, 2012, at 3:34 PM, kirk.john...@zootweb.com wrote:
> Mike Mackintosh <mike.mackint...@angrystatic.com> wrote on 02/17/2012
> 12:36:06 PM:
>
>> On Feb 17, 2012, at 10:57, kirk.john...@zootweb.com wrote:
>>
>>> Is it possible to do an LDAP Password Modify Extended Operation, as
>>> specified in RFC 3062? The password hashing scheme in the LDAP
>>> directory I
>>> am working with may change periodically, so it is my understanding
>>> that I
>>> can't hash a new password according to a specific scheme, e.g., {SHA},
>>> on
>>> my side. Instead, I should use an Extended Operation and let the
>>> directory
>>> do the hashing. Is that correct? The help page for ldap_set_option
>>> suggests that it might be possible, but I sure can't find any example
>>> code
>>> anywhere.
>>>
>>> TIA
>>>
>>> Kirk
>>
>> I have an example of this on my lab box at home. I noticed issues
>> depending on if the requesting application was Linux or windows due
>> to the different Linux LDAP libraries.
>>
>> When I get home I'll forward you the example of what I have so far
>
> Woohoo! Extended Operation doesn't seem to be a practice that is in
> wide-spread use. Looking forward to what you've come up with. Thanks.
Kirk,
What i've been trying to do, is revive the patch i found here:
http://www.mail-archive.com/internals@lists.php.net/msg19665.html
It provides a lot of the functionality that you can only imagine and more, but
it fails against versions 5.3.x.
I sent an email to the original maintainer, Pierangelo, but have not received a
response yet on that status of maintenance.
Do you use OpenLDAP? I am not sure if it built, if it would support AD or not.
Mike Mackintosh
PHP, the drug of choice - www.highonphp.com
--- End Message ---
--- Begin Message ---
I have a script that accepts four POST variables. Three are used and five more
are added for a total of eight keys and their urlencode() values all strung
together in the proper format.
Then cURL is initialized with the field string given to:
curl_setopt($ch, CURLOPT_POST,8);
curl_setopt($ch, CURLOPT_POSTFIELDS, $string);
But that's not the string arriving at cURL's target URL! What's arriving at the
target is exactly the POST array that this script received in the first place.
Here's what I don't understand...
The cURL request is coming from this script on domainA, but the target address
is also domainA. Does everybody play nice in this situation?
PHP 5.3.5
Apache 2.2
Note: CURLOPT_POST evaluates to true, regardless that I use an integer. All
other curl* commands are set.
--- End Message ---
--- Begin Message ---
Am 18.02.12 01:54, schrieb Brian Smither:
> I have a script that accepts four POST variables. Three are used and five
> more are added for a total of eight keys and their urlencode() values all
> strung together in the proper format.
>
> Then cURL is initialized with the field string given to:
> curl_setopt($ch, CURLOPT_POST,8);
> curl_setopt($ch, CURLOPT_POSTFIELDS, $string);
>
> But that's not the string arriving at cURL's target URL! What's arriving at
> the target is exactly the POST array that this script received in the first
> place.
>
> Here's what I don't understand...
> The cURL request is coming from this script on domainA, but the target
> address is also domainA. Does everybody play nice in this situation?
>
> PHP 5.3.5
> Apache 2.2
>
> Note: CURLOPT_POST evaluates to true, regardless that I use an integer. All
> other curl* commands are set.
>
>
>
Maybe you could provide a bit more of information.
var_dump($_POST); // at the beginning of the script
// the code that assembles $string
// the target url for your curl request from curl_init or CURLOPT
// the other curloptions not mentioned here but used
--
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
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
I've done a site from Classic ASP (no .net) to non-oop PHP.
--- End Message ---
