If you create an API key for someone, you might want to save some additional information (for admin purposes) such as:
- application title (already provided by the current 6.x-0.13 release of this module)
but also
- contact person
- contact email adress
- ...

To be able link this information in a flexible way to an API key, we could use CCK integration.
Proposition:
Services module provides a basic node type 'API key profile', with following fields:
- API key (required, auto-generated and non-editable)
- domain name (required - at least with the current hash calculation method)
- application title (optional)

You would then be able to extend this node type with any extra information you'd like to record... and use views to make any list of it, you'd ever want.

Any thoughts on this?

Comments

marcingy’s picture

marcingy commented

The major issue here is that to use that concept would need to convert keys into a node as CCK needs nodes to work with. This of course would cause an overhead and I'm not convinced that the benefit out weight the problems it will cause.

pieterdc’s picture

pieterdc
Primary language Dutch
Location Ghent
commented

You're right, I also thought about the overhead this morning (after some sleep).
I'd like to adjust my proposition.

Services module does NOT provide a basic node type 'API key profile'.
Fields required for authentication belong to the service module itself (or an authentication plugin, but that's kinda off-topic for this issue).
So referring to the current 6.x-0.13 release this would mean:
Services module defines: 'API key' and 'domain name'.

If someone wants to save additional information on a per API key base, he/she would need to:
1. create a node type, with fields like for example: 'application title', 'contact email adress', ...
2. select that node type as placeholder for the extra info on the services' settings page (admin/build/services/settings)
3. click on 'edit additional information' on keys administration page (admin/build/services/keys) (this is a unique link per API key, such as 'edit' and 'delete' are)
4. fill in the info and click 'save'

That way, nobody gets forced to use this feature, but those who want to, can... in a flexible, drupalish way (without the need for the services module to provide all kinds of information one would possibly want per API key).

A quick workaround could be: replace the 'application title' text field by a single textarea 'note' ..

Just posting my thoughts.

marcingy’s picture

marcingy commented
Status: Active » Closed (won't fix)

After more thought if we want to introduce the concept of node based profiles for services this will need to be implemented as a seperate module and utilise the appropriate Drupal hooks to extend the data that is stored against a key etc by using additional form submit handlers