CiviCRM Community Forums (archive)

One problem is that you in effect turn that user key into a password. It lets you perform many (someday, all) actions as that user via the API and other utility scripts like the e-mail sender. So that doesn't necessarily get you anything (except that it doesn't let you into the CMS, which for standalone is a non-issue anyway).

A better approach, in my opinion, would be to not require a username and password for scripts like the e-mail processor but instead severely restrict from which IPs they may connect. By default we'd set it to 127.0.0.1/32 (i.e. localhost) and actively prevent folks from setting it to 0.0.0.0/0 (i.e. world).

The long-term solution, in my mind, is OAuth (http://oauth.net/). But I don't have the time to implement that right now (nor on the horizon).

Hi,

I'm trying to imagine what would be the case of a user that is able to run a php from the civicrm/bin from the shell, but can't READ the civicrm_settings.php file.

In other word, what is the point of requesting the key ? A bad/stupid guy that has access to the shell will simply have to read the setting file and copy the KEY, isn't it ?

I would argue that a much better security is to put the settings in readonly, and add a new variable inside cli_allowed_userid= array ("www-data","xdutoit"). And not let the program run if it isn t one of the linux users defined.

As for the civicrm user (not the linux user), what about adding a second variable listing the allowed civicrm users

cli_allowed_civicrm_users = array ('admin', 'cronuser')


so the linux users www-data and  xdutoit are the only ones that can run a script from the shell, and they can specify it to be run in civicrm as admin or cronuser only.
so:
php bin/EmailProcessor.php -s example.org -u cronuser

would be fine if xdutoit runs it

Again, I really dislike having a password in clear in the crontab (or in the list of process running, or in the apache log for the non cli version). Trying to find a solution as secure (arguably much secure) to replace it.

X+

1. I do think that we should definitely keep the web based invocation also irrespective of where we go with the CLI

Sure it was meant as an alternate access, not a replacement. I'd however suggest to put is as the "most robust" approach in the doc.

2. I do agree that sending in the password via plain text is awful and needs to be fixed. Switching to using the user name and "user api key" is potentially a good workaround

On the REST interface, the user api key is already there. That's just a matter of not putting the password mandatory (I'll need to discuss it with Wes, and obviously make it validated by you, that's a sensitive area).

3. Put all settings in the DB. We need to minimize stuff in settings file

Well, it should be as "protected" as possible and that's probably the same argument in favour of putting the KEY in the civicrm_settings.
Beside, that's about configuring the shell access, would make sense to have that on a config file, isn't it.

This being said, where would you put the config in the db ?

4. If u'll want this change in 3.2, i'd start working on it / tweaking it NOW. Create an svn branch for this and then we can merge it back into trunk once we branch off for 3.1

I'm working on a local copy of the trunk. And won't commit until you branch.