At the risk of oversimplifying the issue:
BAD: eval "MY CODE";
GOOD: eval {MY CODE};
On Tue, May 30, 2017 at 12:00 PM, Hiram Gibbard <hgibb...@gmail.com> wrote:
> I might be hijacking this... Sorry, but...I recently used the Perl eval
> function to determine if a ldap search returned a error or not. Basically,
> a user's record has a attribute that points to a assistant, and If that
> assistant no longer exists the app was throwing a error since it executed a
> ldap call to that assistant's record. So I used eval to check if the error
> was returned, and if so, skipped the function where it tied searched the
> assistant record in ldap. Is this the same eval scenario you described
> which has a security whole?
>
>
> I was just reading everyone's reply and now I am worried I created a
> security hole.
>
> Thanks
>
> On Tue, May 30, 2017 at 10:04 AM, Dirk-Willem van Gulik <
> di...@webweaving.org> wrote:
>
>>
>> > On 30 May 2017, at 16:58, p...@cpan.org wrote:
>> >
>> > On Tuesday 30 May 2017 15:53:13 James Smith wrote:
>> >> String eval should be avoided at all costs [especially if you parse
>> user
>> >> input] - functional eval is different - and is a good model for
>> catching
>> >> errors etc
>> >
>> > Yes, string eval should be avoided in all usage. But this discussion was
>> > about that functional eval.
>>
>> Aye - right you are - apologies for causing confusing and missing the (/{.
>>
>> Dw.
>>
>
>
>
> --
> Hiram Gibbard
> hgibb...@gmail.com
> http://hiramgibbard.com
>
>
--
John Dunlap
*CTO | Lariat *
*Direct:*
*j...@lariat.co <j...@lariat.co>*
*Customer Service:*
877.268.6667
supp...@lariat.co
