Akelos Framework v1 forum archive. This forum is no longer maintained. To report bugs please visit https://github.com/akelos/akelos/issues
    • CommentAuthorThijs
     

    Hi Bermi,

    You added a function that checks the templates for variables in changeset 480.

    Unfortunately I had all kinds of loops in some templates that use counters ($i), and other variables, like:

    <?for($i=1;$i<=$energysources[$meterreading_loop_counter-1]->number_of_meters;$i++){?>
        <? $fieldname = 'energysource['.($meterreading_loop_counter-1).'][reading_'.$i.']'; ?>
        <?= $form_tag_helper->text_field_tag($fieldname,$meterreading->{'reading_'.$i}); ?>
    {end}
    

    And they all generate errors of course. Bummer.

    For now I rolled back to changeset 479 (I've spend too much time on those templates, and I don't now a way to get the same functionality without using vars).

    But I was wondering: Is there a global parameter or other way to disable the checking of variables in the templates?

    •  
      CommentAuthorbermi
     

    Thijs, I also found myself into this situation and I've just added add a config setting to disable this default behavior.

    You can define in your config.php files one of these:

    • AK_PHP_CODE_SANITIZER_SKIP_VARIABLES
    • AK_PHP_CODE_SANITIZER_SKIP_MEMBER_VARIABLES
    • AK_PHP_CODE_SANITIZER_SKIP_FUNCTIONS
    • AK_PHP_CODE_SANITIZER_SKIP_CONSTRUCTS
    • AK_PHP_CODE_SANITIZER_SKIP_CLASSES
    • AK_PHP_CODE_SANITIZER_SKIP_PROTECTED_TYPES

    In your situation you'll need

    define('AK_PHP_CODE_SANITIZER_SKIP_MEMBER_VARIABLES', true);
    

    I'll be committing the changes once I sort some problems with the subversion server. Meanwhile I attach the patch to this thread.

    • CommentAuthorThijs
     

    Great!

    I don't know how to include a patch (don't use subversion), so I'll wait till you checked it in. (I can wait, have other things to do on the same project)

    Glad to know I'll be able to use the latest trunk version again.

    Thnx!

    • CommentAuthorbjmg
     

    @bermi What problems do you have with subversion? Maybe I could help you fixing that problems. Just write me a Mail.

    •  
      CommentAuthorbermi
     

    Bernhard, thanks for your help. I've just sent you an email :)

    •  
      CommentAuthorbermi
     

    Thijs, you can now update your trunk :)

    • CommentAuthorsuthern
     

    Sweet. I noticed that you also updated the way controller->_db->execute excepts variables too (sometime in the mid 400's). Now it's the same as any other area that validates SQL. It would now look like this:

    _db->execute( array('SELECT * FROM some_table WHERE id = ?',$this->params['id']) );

    P.S. if anyone else is new to SVN, the command 'svn update' when in the 'akelos' directory does the trick quite nicely.

    • CommentAuthorThijs
     

    I did a svn update (thanks for the tip) and it 'updated to revision 508'.

    But.. no errors. Those views with the custom variables didn't generate any more errors.
    (which were by the way custom, descriptive Akelos error messages of course)

    So I made a complete checkout

    svn co http://svn.akelos.org/trunk/ akelos
    

    .. but still. No errors. And I didn't set any of the new constants in config.php. And yes, I'm using the newly downloaded lib in my app.

    So I checked in the /lib/, but the changes are there:

        if(!defined('AK_PHP_CODE_SANITIZER_SKIP_VARIABLES') || !AK_PHP_CODE_SANITIZER_SKIP_VARIABLES){
            $this->secureVariables($code);
        }
        if(!defined('AK_PHP_CODE_SANITIZER_SKIP_FUNCTIONS') || !AK_PHP_CODE_SANITIZER_SKIP_FUNCTIONS){
            $this->secureFunctions($code);
        }
        ...
    

    That's odd.

    Anyway. I will not complain for an absence of errors. It's nice like this.

    • CommentAuthorThijs
     

    I DO have the errors now. Probably because the compiled versions of the views needed to be regenerated to initiate a check on the variables used in them.

    And using

    define('AK_PHP_CODE_SANITIZER_SKIP_MEMBER_VARIABLES', true);
    

    makes them go away again. Just like it should be.