- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When making a client (JavaScript) call, a form of authentication is expected by Accept.js. If requires an apiLoginID and a clientKey. So my question is:
What is considered acceptable practice for the storage/display/use of those 2 elements? Not sure if I've worded that clearly though. I'm wondering whether it is considered acceptable/normal, if someone were to "view-source" of the JavaScript that makes the call to Accept.js, that the apiLoginID and clientKey would be viewable in the JS source? If not, what is an example of ways to collect and use them from within the calling function?
Solved! Go to Solution.
โ09-18-2017 12:18 PM
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Because the ClientKey combined with an APILogin only allows you to retrieve a token with encrypted payment data. You still need to use your private TransactionKey, in order to do anything with the token.
The Authorize.Net Client Key is used in place of the traditional Transaction Key. The Client Key is a public key suitable for use where someone other than merchant might see it.
Certified Authorize.net developers
โ09-18-2017 01:37 PM - edited โ09-18-2017 01:39 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Certified Authorize.net developers
โ09-18-2017 01:27 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, that is understood. But still, the question remains.
Why is it secure to have the user (apiLoginID) and the (public) clientKey exposed? Is there domain validation performed, or some other such validation? Or, is it not advisable to have both exposed (via "view source" or similar), as initially asked?
โ09-18-2017 01:31 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Because the ClientKey combined with an APILogin only allows you to retrieve a token with encrypted payment data. You still need to use your private TransactionKey, in order to do anything with the token.
The Authorize.Net Client Key is used in place of the traditional Transaction Key. The Client Key is a public key suitable for use where someone other than merchant might see it.
Certified Authorize.net developers
โ09-18-2017 01:37 PM - edited โ09-18-2017 01:39 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh, ok... So the idea here is that the public clientKey and apiLoginID combination is ONLY good for attaining a Nonce, nothing more? If that's the case, then it makes sense that their both being exposed is not a risk.
Am I now understanding it right? If so, thanks! :D
โ09-18-2017 01:40 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Certified Authorize.net developers
โ09-18-2017 01:43 PM - edited โ09-18-2017 01:44 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, that is understood. But still, the question remains.
Why is it secure to have the user (apiLoginID) and the (public) clientKey exposed? https://www.wizlynxgroup.com/ch/en/ Is there domain validation performed, or some other such validation? Or, is it not advisable to have both exposed (via "view source" or similar), as initially asked?
โ12-31-2022 09:49 PM