March 18, 2019 at 6:21 pm #6008
I’m currently developing an app for a Point of Sales system. I would prefer to make an authentication to the API via an API key insted of saving the username and password. On top it would be awesome if it would be possible to define what features the API key can use and maybe to have more than one key per user for different purposes.
Philipp #CoinVaultOneMarch 19, 2019 at 8:34 am #6014
Unfortunately only the exchange extension was built explicitly with this architecture. The parent plugin does not give you an API key.
However, you can access the JSON API via curl and perform operations with the plugin. Please see the documentation under APIs -> Wallets JSON API -> Accessing the JSON API from cURL for more details. You will also find some documentation on the JSON API in the same document. This is the same API that the frontend uses to communicate with the backend.
Essentially a cookie holds a session ID which you can think of as an “API key” that you are granted as soon as you login with username/password.
Let me know if you need any help with this.
with regardsMarch 19, 2019 at 8:47 am #6017
the biggest problem is that I’m designing a Merchant Customer Point of Sales system and I hate to store login creds in android. An inital login to receive the API key would be fine. How difficult would it be to offer an API key extra to the login creds?
Philipp #CoinVaultOneMarch 19, 2019 at 9:01 am #6018
I understand your concern. This is something that I would like to do.
Perhaps I can try to put something together for the next release, by copying code from the exchange extension.
In any case I will keep you informed about this.
with regardsMarch 19, 2019 at 9:39 am #6020
Thank you very much.March 25, 2019 at 11:02 am #6045
I have copied this feature over from the Exchange extension into the parent plugin, and improved it somewhat. The details are in the documentation file. Please see the relevant release announcement here: https://www.dashed-slug.net/json-api-key-access/
Please let me know if you have any questions about this feature, after reading the relevant part of the documentation.
with regardsMarch 26, 2019 at 9:18 am #6047
you’re awesome thank you very much. I will look into it with my developer and will give you feedback.
Philipp #CoinVaultOneMarch 26, 2019 at 9:33 am #6048
I’m seeing this error message even I’m the admin/editor and have all capabilities:
Error while rendering the api_key shortcode with its default template in /var/www/coinvault/html/wp-content/plugins/wallets/includes/views/api_key/default.php: User with ID 1 does not have the necessary capabilities to view this shortcode.
PhilippMarch 26, 2019 at 9:46 am #6049
Looks like the admin doesn’t have the rights to view the api key. An editor can see it with the capabilities.March 26, 2019 at 10:51 am #6050
Can we add the user_id to the get_nonces command?March 26, 2019 at 12:15 pm #6052
Yes, you need to assign the
access_wallets_apicapability to the user. If you wish to use the API with an administrator account, use any plugin that can edit capabilities to assign
user_idis required for remote access, it can be added to the
get_noncescall. This way you can login first using cookies, obtain the login credentials programmatically, then continue accessing the API using the key. This will be added in the next patch.
with regardsMarch 26, 2019 at 6:28 pm #6056
On top the Wallet API and User ID is missing in the fancy URL: /wallets/api3/get_nonces
PhilippMarch 27, 2019 at 8:17 am #6060
That is correct. For now, you can only do key-based auth with ugly URLs.
This shouldn’t be a problem, as pretty URLs are for end-users only. A developer should be able to use HTTP GET params!
But I am taking a note of your comment, for JSON API version 4!
thank youMarch 27, 2019 at 9:07 am #6064
yes this is no problem just wrote this as info.
Whats the ugly path for the get_transactions? https://example.com/?__wallets_apiversion=3&__wallets_action=get_transactions how to add these values?: /SYMBOL/COUNT/FROM from the fancy path
PhilippMarch 27, 2019 at 9:11 am #6066
Header-based bearer auth is already supported in API version 3, exactly as you describe. You must still pass the user ID as a GET parameter though.
The advantage of this approach is that you are not including secret information in the URL, where it could be logged in server access logs. Version 4, when it is out, will continue to have this feature.
- You must be logged in to reply to this topic.