Error in scheduler.php

[felixkat]

I think it's likely that the commit that Troester pointed out change the way this functions.

I have tested some code which will get this going again via a "Wget" request but not triggered internally as explained earlier, although this can be easily changed as well.

What we need to decide is how we deal with this situation so it's secure and not adding in a zillion options.

The code currently says you cannot truncate, (empty list), if you don't have permission. This is really targetted for the front end CSV import and makes complete sense. It terms of a cron though we have to decide on whether that should be treated as Super User as presumbly anybody who sets up that cron would be.

Alternatively we could create a 'Run As' parameter where we select the user group \ user permission for that cron job.

So if you had a list that had 'Super User' set for empty list the Cron Job would not be able to empty it unless you set the Super User group in the 'Run As' drop down.

Does that makes sense?

 

[rbuelund]

That makes sense

 

[felixkat]

I'll mock up something to test.

 

[felixkat]

I've been reading through the code and I think I'm over-thinking this one.

We have an option in the ImportCSV for 'Drop List Data' and this stopped working due to making the front end CSV Import more secure.

We already have code in place to check if a CSV import is a Cron Import.

  // The csv import class needs to know we are doing a cron import
        $input->set('cron_csvimport', true);

So if you could test the following in the List Model code, /components/com_fabrik/models/list.php around line 3930'ish, replace the canEmpty function with the following.

    public function canEmpty()
    {
        if (!array_key_exists('allow_drop', $this->access))
        {
            $groups = $this->user->getAuthorisedViewLevels();
            $this->access->allow_drop = in_array($this->getParams()->get('allow_drop'), $groups);
        }
       
        /**
        * Cron Permissions
        *
        * If running a cron then assume we want to Empty the List if requested.
        */       
        if ($this->app->input->getString('cron_csvimport', ''))
        {
            $this->access->allow_drop = 1;
           
        }

        return $this->access->allow_drop;
    }

It works on my side but I've had a little battle with getting importcsv to work on Windows which hopefully I've resolved as well now.

 

[cheesegrits]

Nope, that would be too insecure. Anyone could just append &cron_csvimport=1 to a drop request.

-- hugh

 

[felixkat]

So do the same but make query secret compulsory?

 

[cheesegrits]

I'm still undecided. Even once we get the drop issue resolved, there's still add row (I think).

BTW, one workaround is to copy the list, set ACL's accordingly, and use that one for the cron job. Not ideal, but works, and I need to think carefully about the best way to approach this.

-- hugh

 

[rbuelund]

But what if it is not a cron job - but just a load of the webpage that triggers - will this work then ?? Right now I am not using cron only a frontend trigger, and this does not work anymore either.

 

[rbuelund]

Anything new on this ?

 

[rbuelund]

Bump !

 

[cheesegrits]

Did you try this:

BTW, one workaround is to copy the list, set ACL's accordingly, and use that one for the cron job. Not ideal, but works, and I need to think carefully about the best way to approach this.

So the assumption here is that the problem is ACL's. That whatever user loads the page that triggers the task doesn't have delete / empty access on the list. So a way to work round it is to copy the list, set the ACL's lower (so Public has delete row access), and point to that copy of the list from your import. Then I'd suggest adding the 'query string' trigger to it, and triggering it using a UNIX cron job with a wget.

-- hugh

 

[rbuelund]

Ahh now I understand - but that means that anyone could potentially delete the list ? As it is a list I import from a crawler every day - it is not that big harm done, ig it happens - but I would still like this fixed with a proper solution - a code in the end of the url or something like that.

Edit: I just tried to set the access right for deleting post and emtying list to public - then it works.
BUT - There has to be another long-term fix to this.

 

[cheesegrits]

As long as you don't publish any links to that copy of the list, someone would have to work hard to get to it.

Yes, see the discussion earlier on this thread for longer term solutions, but I haven't decided on the best approach yet. Any kind of change to our core ACL code needs a lot of careful thought, and lots of testing before committing to the main branch. So better to do it this way for now, with one limited potential security issue on one list on one site, than I moof up ACL's entirely and every list on every Fabrik install becomes vulnerable.

-- hugh

 

[cheesegrits]

So just to be clear - you copied the list, changed the ACL's on the copy, and changed your scheduled task to use that, right?

-- hugh

 

[rbuelund]

Why should I copy the list ? I just changed the access rights on the list.

 

[cheesegrits]

Because I'm assuming you have link to the list on the front end. If not, don't worry about it. But if you do, then you don't want those links to give row deletion and table empty access to Public.

-- hugh

 

[rbuelund]

Ahh ok - I have removed all buttons in the template

 

[cheesegrits]

Really, trust me, it's much better to copy the list and use the copy for your scheduled tasks.

-- hugh