[Problem] $_POST in Addons Module

[Open Presta]

Hello, 

 

 

i need to use : 

foreach ($_POST as $key => $value)  

but developper addons not accept to use $_POST and Tools::getValue not good for this function 

 

some proposals For that ? 

 

 

[samyha]

Hello, I'm not sure I understand your issue, can you give me more details? About what module are you talking about? (It would be great if you could post a link  )

 

Thanks! 

[Open Presta]

when adding a module addons for sale, prestashop team must validate, and we must replace all $ _POST by Tools :: getvalue 

but in some function we can't like this :  

 

public function copyFromPostOption()
 {
  foreach ($_POST AS $key => $value)
  if (key_exists($key, $this) AND $key != 'id_'.$this->table)
  { 
   if($key == 'content_option')
   {
    foreach ($_POST[$key] as $keyOption=>$opArr)
    {
     if(isset($opArr['opt_fill_column']))
     {
      $_POST[$key][$_POST['type_option']]['opt_fill_column'] = $opArr['opt_fill_column'];
     }
    }
    if ($_POST['type_option'] == 2) //check option static block
    {
     $languages = Language::getLanguages(false);
     foreach ($languages AS $language)
     {
       $temp = str_replace(_PS_BASE_URL_.__PS_BASE_URI__, $this->temp_url,$_POST['content_option'][$_POST['type_option']]['opt_content_static'][(int)($language['id_lang'])]);
       $_POST['content_option'][$_POST['type_option']]['opt_content_static'][(int)($language['id_lang'])] = $temp;
     }
     
     $value = htmlspecialchars(json_encode($_POST['content_option'][$_POST['type_option']]));
     $turned = '\r\n';
     $turn_back = '';
     $value = str_replace( $turned, $turn_back, $value );
    }
    else
    {
     $value = json_encode($_POST['content_option'][$_POST['type_option']]);
    }
    
   }
   $this->{$key} = $value;
  }
 }

1. We can't Replace foreach ($_POST AS $key => $value) with Tools::getvalue and i is not another function 
   
   i see all code in prestashop they also use like this
2. $_POST['content_option'][$_POST['type_option']] Also this Tools::getvalue not enbale to be replaced 

[Emmanuel M.]

Hi,

 

Can you give us more details on why you can't use Tools::getValue?

 

Emmanuel

[Open Presta]

in the 2 place : 

 

1.  foreach ($_POST AS $key => $value)  
2. $_POST['content_option'][$_POST['type_option']] 
   
   we can't use Tools::getValue 

 

[Emmanuel M.]

Ok, but why?

[olea]

Tools::getValue() retrieve params either from the $_GET or from the $_POST

 

As we are in the copyFromPost(), it's logical to retrive only the $_POST, as the Prestashop core does

[Emmanuel M.]

I had never to deal with a variable with the same name in both GET and POST And in this example, I have a really hard time to understand the point of the foreach on the POST to check after if some keys exist...

[olea]

Purpose of the copyFromPost() is to retrieve the object fields value from .... the POST

 

If you use the Tools::getValue(), you may (but not sure) retrieve a value that is given in the GET and that should not be copied into the object

 

copyFromPost() copies from POST, not from POST or GET

[Emmanuel M.]

If you have the same key in the GET and POST at the same time, I think there is a problem with the conception And getValue looks first in the POST.

Seriously, I have never see a case where we can't use getValue !

[bellini13]

simply stated, the function copies all the POST'ed parameters to an internal array, and does some special handling for certain parameters.

 

Therefore the developer has a need to cycle through all of the POST'ed parameters, and Tools::getValue does not allow for this.

 

Regardless if the parameter is in both _POST and _GET arrays is a moot point. 

 

What feature is Prestashop trying to enforce by requiring the use of Tools::getValue anyway?  It is a helper function, and performs some URL encoding and parameter cleansing.  Instead of requiring the use of Tools::getValue, provide a separate helper function that performs the same parameter cleansing, and enforce that is used.

 

To say a developer cannot use _POST directly is an unreasonable requirement, there are many valid use cases for it.  I assume you have searched the Prestashop code and modules, right?  PS themselves use _POST, in fact 1410 matches when I search the PS v1.5.6.2 code base

[leemarkwood]

Can't you use Tools::safePostVars() instead of $_POST?

[bellini13]

seems reasonable to use this to obtain a cleansed array of POST parameters.  I suppose the next question is, why does Prestashop not use their own function?

[MEG Venture]

Can't you use Tools::safePostVars() instead of $_POST?

 

This works OK on Prestashop 1.5, but on 1.6

[bellini13]

This works OK on Prestashop 1.5, but on 1.6

 

Could you elaborate what you concern is?  The safePostVars function exists in PS 1.6

[MEG Venture]

In the class php file

 

If I use Tools::safePostVars() in the foreach loop, the changes on the module configuration page don't work:

	public function copyFromPost()
	{
		/* Classical fields */
		foreach (Tools::safePostVars() AS $key => $value)
			if (key_exists($key, $this) AND $key != 'id_'.$this->table)
				$this->{$key} = $value;

		/* Multilingual fields */
		if (sizeof($this->fieldsValidateLang))
		{
			$languages = Language::getLanguages(false);
			foreach ($languages AS $language)
				foreach ($this->fieldsValidateLang AS $field => $validation) 
					if (Tools::getValue($field.'_'.(int)($language['id_lang']))!= false)
						$this->{$field}[(int)($language['id_lang'])] = Tools::getValue($field.'_'.(int)($language['id_lang']));
		}
	}
}

However, if I use $_POST instead of Tools::safePostVars() everything is OK.

[bellini13]

the same code works in PS 1.5?  But does not work in PS 1.6?

 

You will need to describe exactly what doesn't work

[MEG Venture]

Yes, correct. The loop below works in 1.5, but not in 1.6

foreach (Tools::safePostVars() AS $key => $value)

But instead, if I use $_POST, it works on both.

 

This php file is a class file like modules>blockcmsinfo>infoClass.php of Prestashop 1.6.0.6

 

You can find the same usage there on line 52 in function copyFromPost

[bellini13]

Tools::safePostVars function is identical between 1.5.6.2 and 1.6.0.6, so something else is having an adverse effect here.

 

Now I did look back to PS 1.5.6 and it has a different safePostVars.  So it is PS 1.5.6.1 that introduced a change.  So perhaps the issue is not 1.6.0.6, but instead the new approach introduced with PS 1.5.6.1

 

What version of PS v1.5 did you test where it is working properly?

[olea]

You can't do a foreach on the Tools::safePostVars().

This method modifies the $_POST but doesn't return it modified

[MEG Venture]

What do you suggest instead of $_POST ? Prestashop addons team is currently rejecting modules with $_POST in foreach although there are instances in the default of Prestashop modules.

[MEG Venture]

Any suggestions from the Prestashop team?

[Open Presta]

Any suggession for this how it work with Tools::getValue ? 


 

$return = $_POST['content_option'][$_POST['type_option']]['input_hidden_id'])  

the form like that : 

 

<p>
<label>Fill the column:</label>
<input type="text" class="opt_fill_column" size="20" name="content_option[0][opt_fill_column]" value="1"></p>  

 

[samyha]

Hello everyone,

 

If you have any questions about the conditions of submission of modules on the Addons platform, I invite you to contact the Addons team directly here >> https://addons.prestashop.com/en/contact-us. Make sure to choose the "Selling module on Addons".

 

Have a nice day!

[bellini13]

No offense, but you realize the addons team hardly ever reply to those contact submissions?

[Emmanuel M.]

You can make an array with all the names you want to get, foreach on it and call Tools::getValue() !

[bellini13]

Emmanuel, perhaps you can address the reason for not allowing _POST to be used directly by modules, when PS core uses it about 1400 different locations.

 

If a module wants to iterate through all the posted parameters without having to predefine the expected parameters, what is the issue that addons team is concerned with?

 

Is the issue about sanitizing the data (which is all Tools::getValue is doing), then why not add a new function that allows for sanitizing the data. Then a module can use _POST directly, sanitize the data themselves, and move on...

[leemarkwood]

I think a little wiggle room is required on the accepted use of $_POST. As long as the $_POST variable is ran through Tools::safePostVars() before it's used I really don't see the issue with it. 

 

I guess the main issue is the Addons team just don't have the time to police every modules code, so they just outright refuse all use of $_POST to be safe.

 

A quick solution would be just to make Tools::safePostVars() return $_POST after it was done with it. 

[Open Presta]

I think a little wiggle room is required on the accepted use of $_POST. As long as the $_POST variable is ran through Tools::safePostVars() before it's used I really don't see the issue with it. 

 

I guess the main issue is the Addons team just don't have the time to police every modules code, so they just outright refuse all use of $_POST to be safe.

 

A quick solution would be just to make Tools::safePostVars() return $_POST after it was done with it. 

 

Tools::safePostVars() request a Array post , but not all time we have a array for all