Hello,

Did you enable anon refresh in the backend on the calendar? Otherwise unless you are logged in you will not be able to refresh it with the url.

Many thanks
Tony

Thanks, that solved my problem. Although there does seem to be a bit of an issue with JEvents too. I had set anon refresh within the details for each calendar as I created it, and then set it again to be sure. But this doesn't seem to get stored, although it gives the impression that it will be. It seems to be only the button in the summary of all calendars that is effective.

I wonder if you could consider setting the HTTP return code in the update operation? In the case where the update cannot be done for lack of anon refresh, a return of 403 would make sense. I don't know if there are other error conditions, but if there are, they could also have appropriate codes. Then a small bash script would be able to provide helpful feedback when things go wrong.

Hello,

1. Thank you I'll take a look at that

2. We could, I think the reason we don't is to prevent people trying to brute force the system i.e if you return a 403 people can keep trying until they succeed. Whereas a redirect makes it look as though what they are trying just is not possible.

Many thanks
Tony

Thanks.

I don't know what harm could be done by returning a 403, and it would open up much better possibilities for verifying that the service is working. There is no point using brute force, since there aren't any credentials involved. If anon refresh is off, the request will always fail and there's nothing that can be tried to get round it.

As it is, for those that can manage the cron jobs in a flexible way, it is worth considering using something like:

/usr/bin/cronic /usr/bin/curl -s -k "https://kms.bsr.cloud/index.php?option=com_jevents&icsid=4&task=icals.reload"

The use of cronic suppresses output unless there is an error, but allows output to be sent to the email address specified for cron or crontab. The -k flag on curl avoids SSL certificate checking (which seems to fail for Lets Encrypt certificates). But this still won't report failures resulting from anon refresh being turned off - need 403 for that

Most people test the URL in a browser before creating a cronjob - but you do have a fair point.

If you change lines 277-280 of administrator/components/com_jevents/controllers/icals.php from

			$this->setRedirect( "index.php?option=".JEV_COM_COMPONENT."&task=$redirect_task", "Not Authorised - must be super admin" );

			$this->redirect();

			return;

to

			throw new Exception( JText::_('ALERTNOTAUTH'), 403);

			return false;

It should throw a suitable 403 error.

Thanks for that, I've implemented your suggestion. With a slight modification, a basic cron job can be implemented on one line (I've done it as a jevents file in /etc/cron.d rather than using crontab, but it could be done with crontab):

*/15 * * * * root /usr/bin/cronic /usr/bin/curl -s -k -f -w "\%{http_code}" "https://kms.bsr.cloud/index.php?option=com_jevents&icsid=4&task=icals.reload"

If all is well, there is no output from this. But if the anon refresh is turned off, cron sends an email saying:

Cronic detected failure or error output for the command:

/usr/bin/curl -s -k -f -w %{http_code} https://www.kirkbymoorsidetowncouncil.gov.uk/index.php?option=com_jevents&icsid=4&task=icals.reload



RESULT CODE: 22



ERROR OUTPUT:



STANDARD OUTPUT:

403

Obviously, with a simple bash script, this could be made more sophisticated, the 403 tested and an explanatory message given. This approach also ensures that any error does get reported, rather than simply sending everything to /dev/null which will hide any problems that may arise.

BTW the notifications of new messages from this forum have invalid DKIM, which could affect deliverability.