I see your point of view. Being a server engineer you work with backends, servers, and cloud providers for a living so securing an API hosted by a CDN would not be a significant task for you. However, for many front-end specific engineers dealing with cloud providers can be a difficult task that requires a steep learning curve. To implement a secure connection via a CDN provider it often requires a combination of many components from the cloud provider. We are also aware that there are other ways of integrating 3rd party APIs and only want to provide an alternative that is quicker to use than other options. Furthermore, we are aware that there are different levels of security depending on the approach taken; KOR Connect provides different options for security levels depending on what the project is and the amount of security the connection requires.
If I understand you correctly when you said “Ideally, any third party services also have domain whitelists for the client api calls. So even though its a public key, they're useless elsewhere (even in postman), because it's paired to your domain.” So if you mean that the public API keys that are provided are not used for security but are paired with the domain, then that is how KOR Connect works also.
Reducing latency is very important for us, and we are constantly working to improve this. Once again, given your expertise, optimizing latency may not be as simple for all engineers. As far as KOR Connect throttling performance, we do not have plans to ever do this, but I can see your concerns surrounding this.
Regarding the disclosure of content; this article is published under the KOR Connect organization that requires the company Dev.to account to allow the publishing. The authors are also listed within the Organization page. We will be sure to list who contributed to articles in the future, and maybe publish content on a single account within the organization to prevent this issue in the future. Thank you and we appreciate this advice.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Lol.
Jesus Christ dude.
Hi Jeremy,
I see your point of view. Being a server engineer you work with backends, servers, and cloud providers for a living so securing an API hosted by a CDN would not be a significant task for you. However, for many front-end specific engineers dealing with cloud providers can be a difficult task that requires a steep learning curve. To implement a secure connection via a CDN provider it often requires a combination of many components from the cloud provider. We are also aware that there are other ways of integrating 3rd party APIs and only want to provide an alternative that is quicker to use than other options. Furthermore, we are aware that there are different levels of security depending on the approach taken; KOR Connect provides different options for security levels depending on what the project is and the amount of security the connection requires.
If I understand you correctly when you said “Ideally, any third party services also have domain whitelists for the client api calls. So even though its a public key, they're useless elsewhere (even in postman), because it's paired to your domain.” So if you mean that the public API keys that are provided are not used for security but are paired with the domain, then that is how KOR Connect works also.
Reducing latency is very important for us, and we are constantly working to improve this. Once again, given your expertise, optimizing latency may not be as simple for all engineers. As far as KOR Connect throttling performance, we do not have plans to ever do this, but I can see your concerns surrounding this.
Regarding the disclosure of content; this article is published under the KOR Connect organization that requires the company Dev.to account to allow the publishing. The authors are also listed within the Organization page. We will be sure to list who contributed to articles in the future, and maybe publish content on a single account within the organization to prevent this issue in the future. Thank you and we appreciate this advice.