[Feature Request] API Key Auth instead of Login Creds

[Anonymous]

Hi Alex.

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.

Regards
Philipp #CoinVaultOne

[alexg]

Hello Philipp,

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 regards

[Anonymous]

Hi Alex,

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?

Regards
Philipp #CoinVaultOne

[alexg]

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 regards

[Anonymous]

Thank you very much.

[alexg]

Hello,

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 regards

[Anonymous]

Hey Alex,

you’re awesome thank you very much. I will look into it with my developer and will give you feedback.

Regards
Philipp #CoinVaultOne

[Anonymous]

Hi Alex,

quick response:

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.

Any idea?

Regards
Philipp

[Anonymous]

Looks like the admin doesn’t have the rights to view the api key. An editor can see it with the capabilities.

[Anonymous]

Can we add the user_id to the get_nonces command?

[alexg]

Hello,

Yes, you need to assign the access_wallets_api capability to the user. If you wish to use the API with an administrator account, use any plugin that can edit capabilities to assign access_wallets_api.

Since the user_id is required for remote access, it can be added to the get_nonces call. 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 regards

[Anonymous]

Hi Alex,

sounds good.

On top the Wallet API and User ID is missing in the fancy URL: /wallets/api3/get_nonces

Regards
Philipp

[alexg]

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 you

[Anonymous]

Hi Alex,

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

Thanks
Philipp

[alexg]

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.

with regards

[Author]

Posts