CiviCRM Community Forums (archive)

Do you think you'll be able to share the new api you created before the code freeze end of the month ?

I hope so.  I'm trying to push the team along to get at least the library completed, even if the other aspects of that project need more time.  I caused a significant delay in the process, so I don't want to appear to be too demanding, but at the same time I understand that others are going eager to get this moving.

Aaron

Hi,

Of course I try not to break it. You can still use the key and handle the session via the cookie as you do now. The only difference is that the key returned by the login doesn't matter anymore, but it's still there for compatibility reason.

We might as well put a "OBSOLETED, use PHPSESSID" as a default key ?

X+

The standalone implementation is already sorely in need of a different way to authenticate for REST calls. Using an OpenID for machine-to-machine auth seems rather cumbersome (standalone uses OpenID for regular user auth).

It sounds like the direction you all are headed in will help here, but wanted to put this on your radar screen too. I'm happy to help if standalone isn't something you're particularly interested in.

I love the move towards statelessness, but what about the other aspects of REST? Namely, making everything a resource and then operating on those resources via GET, PUT, POST, DELETE HTTP verbs? Would be great to see that happen and then have CiviCRM's web interface be the flagship client for it (but not the only one).

With that in place, we could get the various front-ends (standalone, Drupal module, Joomla! module, XML / JSON feeds) to use a common REST interface for interacting with the back-end of the system. Then we fully document that REST API, keep it pretty stable across minor revisions, and voila, CiviCRM the platform is born.

So I'm back to asking:  Lobo, what would it take to get a field in the database to store some kind of secret-key for the REST interface to use? 

we can do this for 2.2. We prefer not to change the schema once a release happens (i.e. lets not do this in 2.1)

should we call it secret_key and make it varchar(32)?

lobo

I would much rather see the field be in the database.  This would allow us to easily add a way to modify the field in the user interface (have a display field, and a regenerate button).  I'm not sure that it will make development significantly harder, and it seems more consistent and cleaner to me.

I agree that Lobo et al. have final say, and I'm happy to defer their experience/wisdom/autocratic rule.  

Let me see if I understand what your suggesting because we are clearly talking at cross purposes here.
You are suggesting that we create a key that lives in a file someplace, that when connecting on a non-authenticated session you would have to provide as part of the query string (?q=civicrm/command&key=data_from_file).  Would you also then provide a username/password pair on every call as well  (?q=civicrm/command&key=data_from_file&user=UserName&password=Password)?  Am I understanding your suggestion correctly?

From how I see it, the long form of this is required to make it work smoothly over time (see discussion of security integration below), but it would be overkill without adding security to the connection. 

What I am proposing is that the User Framework be augmented to handle the extra field (not contacts that have no user).  Perhaps there is a good reason not to do this, and I certainly didn't explain it as carefully as I should have yesterday when I requested the field. The user would then provide one of two things on a call either a valid PHPSESSIONID (like your current patch provides), or a key that would allow authentication as the user (?q=civicrm/command&key=user_specific_key).

I think the security considerations here are offsetting.  On the one hand you're right, rarely to people manage user access correctly and placing the key in the interface does create a place it can be captured by an attacker.  However, the PHPSESSIONID is just as susceptible to MIM attacks and session hijacking if you run over an unencrypted connection.  If you're worried about someone picking off the key in this fashion, you need to be running an encrypted connection anyway.  And if you manage security badly, then you will do that with a shared key or user-specific key, I don't really see an advantage here either way.

The advantages of the individual keys as I see them are that is makes integration into the security system easier and makes the user experience better.  It also avoids us from having to have another file that people have to know exists (or can exist) and maintain.

Having a key per user allows us to run the API within the security system of CiviCRM, instead of having to bolt-on special controls for key-based usage. It could allow us to honor ACLs (even if we don't at first) and other forms of controlling access. Going with a shared key also makes me feel like we're talking about adding challenges later when ACLs are changed, or other new forms of access control are added.

It also allows to continue to control access rights in one place, not two.  I think there is a risk with a file-based key that we could open some users up to thinking they have cut access off, only to discover that there is a backdoor they forgot existed.

I'm all for a whitelist, but how the heck do we manage it in a user friendly way?

Aaron

(ok, i had typed in a response before the last two messages came in, so am now reevaluating

so the latest suggestion that all api calls are of the form:

?q=civicrm/command&key=SOME_SECRET_KEY

and then the code does a db lookup to find the contactID that matches the KEY and ensure there is a userID before doing the operation?

I initially agreed with xavier and wanted to keep things simple and file based, but I've changed my position and now agree with aaron Doing it at the contact level to begin with allows us to have more options down the road. its not a bit change (from a db/code perspective), and can accomodate xaviers case very easily (i.e. the admin sets the key for only one specific contact). I think since this key is so special, we can keep the interface separate from the contact edit screen

lobo

With that in place, we could get the various front-ends (standalone, Drupal module, Joomla! module, XML / JSON feeds) to use a common REST interface for interacting with the back-end of the system. Then we fully document that REST API, keep it pretty stable across minor revisions, and voila, CiviCRM the platform is born.

I'm not too fond of this idea.  Someone correct me if I'm misunderstanding.  The above implies that when civicrm_hook_user() gets fired it would perform an HTTP request to the REST interface instead of directly calling other CiviCRM functions.  This would mean that every time a user submits a registration form, a user edit form etc. a second HTTP request is made.  This would be a considerable hit for some of our bigger high traffic sites.  Especially when doing any sort of bulk operations on users.

I can see the benefit of autocomplete forms etc. using the REST interface, but not for other front-end activity. 

example.org/rest/entity/action

I would prefer example.org/civicrm/rest/entity/action to avoid namespace collisions.  After all, the REST API is only for CiviCRM and not for all of example.org.

What's the point of the intermediate key->contact->user instead of key->user

Because CiviCRM calculates ACL both on the user level and the contact level.  A REST API should respect both.  An autocomplete form should not return information that the current contact doesn't have access to (due to CiviCRM's internal contact level ACL).  And so that a user who no longer has access to CiviCRM (via the "Access CiviCRM" user permission) doesn't have an open backdoor via the REST API.