Would be nice to update the docs!!
Thanks for the feedback i will check on what the docs say (or don’t ) about this now
1 Like
Thanks Brian!
Users may be calling external systems to display data in the Kinetic UI, so having a broader strategy of implementing secret management instead of embedding API KEYs in the source code would still be useful.
2 Likes
The asterisk on the field also gives the impression that it is required.
2022.1.10
3 Likes
sounds like a bug to me - i’ll have that corrected, thanks for noting it
1 Like
Yep i did read your idea there and that makes a lot of sense for opening up more abilities to safely call outbound to non-epicor apis from ui customizations. Esp those that use an authentication baked api key. We will consider adding a feature like that.
It’s also a good way to solve all of the greenlisting and cors constraints.
7 Likes
Thanks for the explanation as to why Brian.
2 Likes
I see API key is no longer showing as a required field in 2023.1!!! But sitting in insights class right now where they are still telling us its required.
2 Likes
Yeah I was talking with one of the devs in the back before it came up and asked if the presenter knew it wasn’t required for internal calls.
She said probably not, and then it came up.
It’s not required, they just need to update the guidance and education.
1 Like
Vote for this idea to have it work with both internal and external API-KEYs, among other secrets. Unlike passwords for humans, keys should be rotated more often. Putting them in source code is just a Bad Idea.
(As is making them available in the client. A BFF would be nice.)
3 Likes