I have an AIO instance running 18.01 OPDK and when I try to update a developer app using this API documentation it's not updating the keyExpiresIn field, even though the doc says that it should be updated.
Is this a known issue?
is there another way to update that field?
Solved! Go to Solution.
Thanks for your question. It's a good one.
I'm not sure about the documentation. I can tell you how it actually works, though.
The key thing: There is no way to update keyExpiresIn.
You said you wanted to update a developer app to modify the expiry. But: An expiry value is not part of the developer app; a developer app does not expire. If you query any developer app with the API, you will see expiry values as part of the CREDENTIAL or credentials associated with the app. The app has a 1:N relationship with credentials. You may have understood all of this, but I want to be as precise and clear as possible on this. Expiry applies to credentials, not apps.
OK now, having said that, the mgmt API for creating an app can be a little confusing for a couple reasons.
Back when the API was created, someone thought it would be handy to implicitly and automatically create a single credential when the Admin API was called to create an app. Who wants an app with no credentials, right?
So when creating an app, you can optionally pass in keyExpiresIn as a toplevel field in the JSON (or XML if you like). But, if present, that field applies ONLY to the credential that is automatically (implicitly) generated when you create the app. That field is not stored with the app, and doesn't apply to the app. If the field isn't present, you get a credential that never expires. Following RESTful design, maybe it would have been better to accept a query param like "expiryForInitialKey" , rather than accepting "keyExpiresIn" in the payload.
If you later add another credential to the app, you again need to specify keyExpiresIn for that credential, if you want one. The app doesn't "remember" the keyExpiresIn that you used for the initial credential. There are no smarts in the backend logic to look in previously created credentials and use the expiry that was used there, for newly created credentials.
To repeat, you cannot update the expiry (expiresAt) of a credential. You can:
You can also:
Also:
Does this clarify things?
If you point me to a specific doc page that contradicts any of the above, I will first apologize about the misinformation, and then I'll make sure we get the doc page fixed.
Thanks for your question. It's a good one.
I'm not sure about the documentation. I can tell you how it actually works, though.
The key thing: There is no way to update keyExpiresIn.
You said you wanted to update a developer app to modify the expiry. But: An expiry value is not part of the developer app; a developer app does not expire. If you query any developer app with the API, you will see expiry values as part of the CREDENTIAL or credentials associated with the app. The app has a 1:N relationship with credentials. You may have understood all of this, but I want to be as precise and clear as possible on this. Expiry applies to credentials, not apps.
OK now, having said that, the mgmt API for creating an app can be a little confusing for a couple reasons.
Back when the API was created, someone thought it would be handy to implicitly and automatically create a single credential when the Admin API was called to create an app. Who wants an app with no credentials, right?
So when creating an app, you can optionally pass in keyExpiresIn as a toplevel field in the JSON (or XML if you like). But, if present, that field applies ONLY to the credential that is automatically (implicitly) generated when you create the app. That field is not stored with the app, and doesn't apply to the app. If the field isn't present, you get a credential that never expires. Following RESTful design, maybe it would have been better to accept a query param like "expiryForInitialKey" , rather than accepting "keyExpiresIn" in the payload.
If you later add another credential to the app, you again need to specify keyExpiresIn for that credential, if you want one. The app doesn't "remember" the keyExpiresIn that you used for the initial credential. There are no smarts in the backend logic to look in previously created credentials and use the expiry that was used there, for newly created credentials.
To repeat, you cannot update the expiry (expiresAt) of a credential. You can:
You can also:
Also:
Does this clarify things?
If you point me to a specific doc page that contradicts any of the above, I will first apologize about the misinformation, and then I'll make sure we get the doc page fixed.
Thanks Dino that definitely helps.
The doc from the original post seems misleading to me. The fact that you can send keyExpiresIn as part of the payload for a PUT made me think that it's possible to update that value.
Thanks for pointing this out, @Matias, and thanks for the great write-up, @Dino-at-Google. I've removed keyExpiresIn from that API doc.
User | Count |
---|---|
2 | |
1 | |
1 | |
1 | |
1 |