Is it possible to migrate the existing client ID and client secret after it is provisioned?

 
Solved Solved
2 16 2,346
2 ACCEPTED SOLUTIONS

Yes. It is very much possible to migrate the existing client ID and client secret. Below are the curl calls to do so.

Create Key :

curl -H 'Content-type:application/xml' -u user:pwd https://${management-server}/v1/o/${org_name}/developers/${dev_email}/apps/app1/keys/create -X POST -d @/tmp/key.xml 

Update Key :

curl -H 'Content-type:application/xml' -u user:pwd https://${management-server}/v1/o/${org_name}/developers/${dev_email}/apps/app1/keys/${KEY} -X POST -d @/tmp/key.xml

Delete Existing Key :

curl -H 'Accept: application/xml' -H 'Content-type:application/xml' -u user:pwd https://${management-server}/v1/o/${org_name}/developers/${dev_email}/apps/app1/keys/${KEY} -X DELETE

View solution in original post

@vednath pittala

Please find your answers below :

I just tried out the flow and it works. So you have to make all the three calls in sequence as @Akash Prabhashankar has mentioned.

a) In the first call it creates (i.e. imports your API key) in the particular environment. For reason (and the reason might very well be a bug) it does not automatically associate the key with a product . So after 1st step you will see the key is imported but the product associated is null.

b) Thats why call 2 is needed. It is basically updating the API product with the API Key.

c) At this stage if you go to the UI you will still not see the newly imported API key. But if you make a call to the following API you will see your App has both the Apikeys :

     curl -H 'Content-type:application/xml' -u "uname:pwd" "https://api.enterprise.apigee.net/v1/o/{orgName}/developers/{dev_email}/apps/{app_name}" 

DELETE the original api key. And then go back to the UI and you will see only the newly imported key being present against the app

It is not the most intuitive solution , I agree , but it works.

You can use this tool as well : https://github.com/apigeecs/apigee-migrate-tool.

This has a command to migrate API keys. which under the hood basically makes all the above API calls in that sequence.

Let me know if this helps

View solution in original post

16 REPLIES 16

Yes. It is very much possible to migrate the existing client ID and client secret. Below are the curl calls to do so.

Create Key :

curl -H 'Content-type:application/xml' -u user:pwd https://${management-server}/v1/o/${org_name}/developers/${dev_email}/apps/app1/keys/create -X POST -d @/tmp/key.xml 

Update Key :

curl -H 'Content-type:application/xml' -u user:pwd https://${management-server}/v1/o/${org_name}/developers/${dev_email}/apps/app1/keys/${KEY} -X POST -d @/tmp/key.xml

Delete Existing Key :

curl -H 'Accept: application/xml' -H 'Content-type:application/xml' -u user:pwd https://${management-server}/v1/o/${org_name}/developers/${dev_email}/apps/app1/keys/${KEY} -X DELETE

The format for the xml is as shown below.

/tmp/key.xml

<CredentialRequest> 
<ConsumerKey>${KEY}</ConsumerKey> 
<ConsumerSecret>${SECRET}</ConsumerSecret> 
<ApiProducts> 
<ApiProduct>${API_Product}</ApiProduct> 
</ApiProducts> 
</CredentialRequest> 

Dear @Akash Prabhashankar , Yes, Above solution works but make sure you give enough time between create / update / delete calls for cassandra to sync. Otherwise it will result in inconsistent data. We have seen some issues with above curl calls executed with minimal time.

The create call does not work as I expected. It does create the new key but does not attach it to an API Product. This is the response:

{  "apiProducts" : [ ]
,  "attributes" : [ ]
,  "consumerKey" : "LwAWRqaIG9uA4fq3PEBfher3QbZY1bbG"
,  "consumerSecret" : "LRwhKr4CiCqGNbVF"
,  "issuedAt" : 1435668690960
,  "scopes" : [ ]
,  "status" : "approved"
}

I tested it in a Developer account in the Apigee cloud.

Here is the json equivalent, for those so inclined:

# Create a new key on existing app
curl -i -n -X POST \
   https://api.enterprise.apigee.com/v1/o/ORGNAME/developers/DEVELOPER/apps/APPNAME/keys/create \
  -H "Content-type: application/json" \
  -d '{ 
  "consumerKey" : "CustomKeyGoesHere",
  "consumerSecret" : "secretGoesHere-ItCanBeQuiteLong"
}'


# Attach that key to an existing product

curl -i -n -X POST -H 'Content-type:application/json' \
   https://api.enterprise.apigee.com/v1/o/ORGNAME/developers/DEVELOPER/apps/APPNAME/keys/CustomKeyGoesH... \
  -d '{  "apiProducts" : [ "ProductNameHere" ]  }'


Note, the apiProducts is a list of strings, each one the name of an API Product in the organization.

Hi Akash,

We have recently migrated all our developer apps to company apps.

Problem we are facing is, As a part of security feature, we use verify access token mechanism in our projects. We create a non expiry access token and share it with business team. During the app migration, access token generated using key and secret of developer app got deleted and is no longer valid. Business had to reconfigure the new access tokens in their systems.

Before I do this in production, I would like to know if there is any other way to overcome this.

Thanks,

Anusha.

Hi, your question seems like a brand new question.

please post it via the Ask A Question button.

7440-ask-a-question.png

@sarthak please provide answer to my last 2 comments. This is the solution am looking for. Also while creating a key it expects the app to be there and when creating an app through UI app creation and key creation happen at the same time(else it would not allow you to save the app unless you associate it with product and key) is there a way to de-couple them and make app creation as one transaction and key creation as another?

@vednath pittala

Please find your answers below :

I just tried out the flow and it works. So you have to make all the three calls in sequence as @Akash Prabhashankar has mentioned.

a) In the first call it creates (i.e. imports your API key) in the particular environment. For reason (and the reason might very well be a bug) it does not automatically associate the key with a product . So after 1st step you will see the key is imported but the product associated is null.

b) Thats why call 2 is needed. It is basically updating the API product with the API Key.

c) At this stage if you go to the UI you will still not see the newly imported API key. But if you make a call to the following API you will see your App has both the Apikeys :

     curl -H 'Content-type:application/xml' -u "uname:pwd" "https://api.enterprise.apigee.net/v1/o/{orgName}/developers/{dev_email}/apps/{app_name}" 

DELETE the original api key. And then go back to the UI and you will see only the newly imported key being present against the app

It is not the most intuitive solution , I agree , but it works.

You can use this tool as well : https://github.com/apigeecs/apigee-migrate-tool.

This has a command to migrate API keys. which under the hood basically makes all the above API calls in that sequence.

Let me know if this helps

I have the same issue as @kbouwmeester what should i do to associate it back with a Product?On the Product page it does show that the app is associated with it but it doesnot show the key as approved. Please suggest to help me resolve this issue

Also the above curl command for update expects same key value in both the xml as well as the request. So how do we change the key if it expects same value?

Thanks @sarthak as you said it works but the process is not very intuitive. Will give it a try with the migrate tool and see.

FYI, I've created a doc topic for this, as well as a new SmartDocs topic to make the 'create' call.

http://apigee.com/docs/developer-services/content/import-existing-consumer-keys-and-secrets

I changed the sample curl calls to JSON payloads that don't duplicate payload details.

Can someone help me on above thread as I tried to change the consumerKey and consumerSecret key which was mention by @Dino was able to connect but not able to create the new key for the particular app?

I am getting some issue in this.

curl -i -n -X POST \
   https://api.enterprise.apigee.com/v1/o/ORGNAME/developers/DEVELOPER/apps/APPNAME/keys/create \
  -H "Content-type: application/json" \
  -d '{ 
  "consumerKey" : "CustomKeyGoesHere",
  "consumerSecret" : "secretGoesHere-ItCanBeQuiteLong"
}'


Note: Unnecessary use of -X or --request, POST is already inferred.
* Rebuilt URL to: consumerKey:/
* Could not resolve host: consumerKey
* Closing connection 1
curl: (6) Could not resolve host: consumerKey
Note: Unnecessary use of -X or --request, POST is already inferred.
* Rebuilt URL to: 0vTJEhPYixO2YMqyrYTksEOcW2cZXcJQ,/
* Could not resolve host: 0vTJEhPYixO2YMqyrYTksEOcW2cZXcJQ,
* Closing connection 2
curl: (6) Could not resolve host: 0vTJEhPYixO2YMqyrYTksEOcW2cZXcJQ,
Note: Unnecessary use of -X or --request, POST is already inferred.
* Rebuilt URL to: consumerSecret:/
* Could not resolve host: consumerSecret
* Closing connection 3
curl: (6) Could not resolve host: consumerSecret
Note: Unnecessary use of -X or --request, POST is already inferred.
* Rebuilt URL to: pcre5AcVgFfyBpo1/
* Could not resolve host: pcre5AcVgFfyBpo1
* Closing connection 4
curl: (6) Could not resolve host: pcre5AcVgFfyBpo1
curl: (3) [globbing] unmatched close brace/bracket in column 1

The curl command you are running is being consumed by the shell. I would drop the -i and -n

options and then try again. Basically curl is seeing consumerKey as a host value for example

" could not resolve host: consumerKey".

Thanks @rblewitt1