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
_______________________________________________
Roundcube Development discussion mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/dev
