Not all crons run in CLI mode. You can't run in CLI mode if you want to give users the ability to use external cronjob services unless you use a script which is called by the external service by HTTP to start a shell script.
which completly defeats the idea of CSRF
So, you are saying that those who are not able to run crons by calling a shell script (shared hosting) should not be able to run Roundcube and its plugins?
i would not do that and looking at the price of a VPS where you can run real cronjobs i don't see a reason
As far as I understand CSFR it should prevent POST and AJAX-Requests from not authorized sources and nothing else
- a cronjob is a serverside action
- a serverside action must not be triggered uncrontrolled
Why do you have concerns to run HTTP based cronjobs?
because it's likely unsecure in many situations and you open a can of worms because it fights with server configurations and ressource limits because it fights with timeouts and what not
Well, this is off topic here. So, let's move this discussion to another topic.
you came with cronjobs over http
I don't want to have sessions started when it is not needed
and it *is needed* for CSRF protection of the login form
I'm not convinced by your argumentation. Why? Because at the end of time you are saying that plugin developers don't know what they have to do and they have to be protected against their own code.
the server admin needs to be protected
Well, I don't think an admin installs untrusted code.
As said, let's move this discussion to another topic. It is off topic here.
If it your opinion that the login page has to be CSFR protected then OK. BUT I don't want to have sessions started just for CSFR prevention for ANY code which is executed in not authenticated state. Roundcube developers did their job to provide secure code since they OFFER CSFR prevention. It is not their job to TOTALLY lock things for others who know what they are doing. Once again: As a consequence you have to ask to remove the 'startup' hook or (even more secure) to move plugins API initialization behind login (disallow any kind of third party code injection). I really hope that you never will be heard with such a request.
that's why possible ressource intensive and long running things typically are not done within the webserver process
Isn't it true, that I have to know what is resource consuming when running code on Roundcube's startup hook? So, if your arguments are valid then you have to start a discussion about removal of 'startup' hook from Roundcube and to disallow code execution at all in not authenticated state. I'm curious what other plugin developers will say to such a consequence.
honestly *yes* there should not run any non-trivial code except session-management, CSRF protection and display the login form before successful authentication
not only for roundcube, for any web application
Of course there are IP or authorization token checks. I didn't say that Devs should disable security features.
but don't start a session because a random GET parameter leads in two options, none of them makes sense
- your request does anyways not work because the CSFR
- you disable also CSFR if the param is given which is not smart to
say it polite
See my comments above in regards to Roundcube's 'startup' hook
honestly i don't care about plugins and the web applications i am writing for more than 11 years now are all stripped down to not load any piece of un-needed ... ... code in whatever state as well as there are no maintainance operations over http without authentication, anything else is done in *real* cronjobs with a own user, his own php.ini and his own restrictions
after serious attacks (trying intrusion as well as DDOS) you know why and if it comes to security anybody who tries to setup here cronjobs called via the webserver no longer has access to do anything possible harmful