A consumer is another web application that is allowed to send requests to this application on behalf of an authorized user. In other words, a consumer is a client application that consumes (or possibly generates/updates) the information of ${local-app} (through this app) using an authorized ${local-app} user.
Consumers are needed to create incoming OSLC Links; this means you need to register the OSLC Remote Application as a consumer of ${local-app}, if you want to create OSLC Links on the OSLC Remote Application side; keep in mind that additional configuration will be required also there, but for now let's focus on the requirements of this side.
There are two types of consumers (depending on the type of its Key):
Another way of categorizing consumers is whether they are trusted or not:
Next procedures focus on actions you can do in the consumers page, this means the registry and removal of consumers is about consumers with authorized key; it also means you won't find a procedure to register a consumer with a provisional key.
Add Consumer button on top right.Add Consumer dialog according to the following field descriptions:
| Field | Required | Description | Notes | Suggested Value |
|---|---|---|---|---|
Name |
Yes | Logical name for human identification. | Commonly the client application name. | The OSLC Remote Application name. |
Key |
No | Unique consumer identifier. | System will generate one for you if not provided. | Leave it empty |
Secret |
Yes | Consumer password. | Along with Key, required for consumer authentication. |
Whatever you want you don't forget. |
Confirmation |
Yes | Password confirmation. | Just a confirmation field to avoid password typos. | The same as Secret field. |
Functional User |
No | User to work in behalf of. | Required in specific scenarios where direct server to server authentication is required. | |
Trusted |
Yes | Whether a consumer will be trusted or not. | Check to avoid extra user authorization on each session. | checked |
Add button.If everything went OK, a new consumer entry will be displayed on the Authorized Keys
section; note: the Secret field is hidden. If you decided to provide a custom Key field value, make sure there is not an existing
consumer with the same key or you will get an error message from the system.
Authorized Keys section and table at the bottom of the center panel.OK button in the confirmation dialog.If everything went OK, the chosen consumer will be deleted from the system and it will no longer appear on the table.
Authorized Keys section and table at the bottom of the center panel.Update button to save these changes.If a remote friend application requested a provisional key, such request will be waiting an approval/rejection from the ${local-app} server administrator. The friend application won't be able to connect to ${local-app} while this request is not approved. To approve/reject provisional key requests:
Provisional Keys section and table in the middle of the center panel.Authorized column,
depending on what you want to do:Approve to accept the provisional key request.Reject to reject the provisional key request.Save button.You can approve/reject multiple keys at the same time. If you chose to accept a request, the key entry will be moved to the Authorized Keys
section and table; otherwise it will be removed from the current table. Note: provisional-key consumers will be trusted or untrusted
depending on how they were requested; if you want to change this, follow the Updating a Consumer steps.