Impact 2024: The Industrial Data and AI Conference for and by Users | Nominate Speakers Now for a Ch...
Hi Thomas,Thanks for the feedback on the Python SDK. We will have a look at how it can fit into our roadmap! We would love to get more feedback on the SDKs so any additional input is greatly appreciated.Regards,Omar
Hi Henning,Thanks for your patience, here is the npm package for the react-auth-wrapper: https://www.npmjs.com/package/@cognite/react-auth-wrapper. Any feedback would be highly appreciated!Kindest RegardsOmar
Hi Henning, we are aware of this issue and we are working on a fix asap.
Hi Andreas, Here is the link to the code samples mentioned above: https://github.com/cognitedata/cognite-sdk-js/tree/master/samples/react. If you are using node.js here are the code sample for that: https://github.com/cognitedata/cognite-sdk-js/tree/master/samples/nodejs. Let me know if this helps :)
Hi Henning. Were you able to resolve this issue? Wanted to follow up to see how it went
Hi Henning.For doing global promise rejection you can use this link. This will enable you to handle all the unhandled promise rejections. When it comes to having similar functionality in the SDK, this is valuable insight as we currently do not offer such a thing.Let me know if this helpsKindest RegardsOmar
Hi Henning,There are two approaches to global error handling in the JavaScript SDK. For a React application, it is recommended to use a component around all your code and store the errors inside a context (data storage) shown in this component. For a NodeJS application, it is recommended to use a middleware that will catch the error and highlight it.For Cognite API related errors, we do have some documentation on that in the API reference doc (https://docs.cognite.com/api/v1/) I hope this helpsRegardsOmar
Hi thomasfred,Thank you for providing feedback. We always look to improve the user experience using the SDKs, especially when it comes to an important feature such as authentication.Currently authentication lives outside the JavaScript SDK, meaning some code needs to be written for both API and OIDC authentication. See code samples. A next iteration of this, we will aim to reduce the amount of code the user will have to write. There are a couple of ways to approach this, your suggestion being one of them.To answer your questions, we would only offer using tokens more specifically (OIDC) at the start with API login being the same as before. Benefits of having a CDF Client connection string lie in its simplicity. But this also comes with drawbacks such as reduced security for the client secret. In general, I completely agree that there should be a standardised approach to authentication across all SDKs and that is something we aim for.Kindest regardsOmar
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.