You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.
I have spent two days trying to understand why the following does not work in CCP:
$my_postcode = "OX15";
if ( $my_postcode =~ /(OX15|PY10)/ )
{$snag = "YES";}
else
{$snag = "NO";}
RESULT: $snag = 'NO'
I have tried countless variations "/OX15|PY10/i" "m/(OX15|PY10)/ etc and I cannot get this to match. From my research, this should diffinately set the $snag to "YES". If I just set the regular expression to "/OX15/", it matches fine. It looks like it is the " | " character that it is having a problem with.
ANY THOUGHTS ANYONE?
Offline
This is a custom shipping script (portion thereof), right? That being the case, I can confirm that pipes ( the | character) are not allowed in custom shipping scripts. It's valid PERL, just not allowed in shipping scripts for some reason. Change it to an OR format and you'll be fine. Ie:
if ($my_postcode =~ /OX15/ OR $my_postcode =~ /PY10/)
It stinks that the ability to use a proper regex is so handicapped by this limitation, but I believe it was done for security purposes. In any case, that's the way it is, so we just have to work around it.
Offline
Thanks for the super quick reply.
Yes, you are right, it is the shipping script I am trying to amend.
Offline
I wonder if there is a way to disable this for the shipping scripts?
Offline
Oh probably... most anything is possible. But since it is definitely security related (stopping potential malicious code), I just never even looked into it. A quick look at the code suggests that the relevant portion is in ste_chkout.pl, in the subroutine ste_chkout_meth_custom_proc, right after this comment (around line 3545 or thereabouts):
######### ######### Remove backtics, pipes, system, die and exec to reduce ######### the possibility of a hazardous effect on the server as ######### a result of running this code. Luckily the webserver ######### can usually only affect world writable and in some cases ######### user owned files. There should be no danger to the ######### filesystem, but it's good to do a little preventive ######### counterhacking. #########
Looks easy enough to modify, but I don't want to suggest anything that could weaken security, so you're on your own from here.
Offline
Thanks for that update.
I hashed out these lines and it did allow the PIPE to be used:
$custom_script_code =~ s/\|\|/%7C%7C/g;
$custom_script_code =~ s/\|/ /gs;
$custom_script_code =~ s/%7C%7C/\|\|/g;
I would be interested in any views as to why the "|" character could have a malicious use?
Offline
Perhaps not so much malicious as inadvertent screwing things by bad code? In Unix/Linux, the pipe character is used to redirect output, such as to a file or a printer. Perhaps the concern was that improper use of it in the shipping script could cause accidental unintended consequences?
Offline