A new signal to allow api login requests through an external service

[Dimfred]

User Story
As a bitshares node operator I'd like to give the users the best experience.

In terms of api_logins the user is required to verify himself. Therefore the bitshares blockchain offers the api_access_info. This file is loaded on startup of the node. To add a new user and make the change available, the node has to be restarted. That is pretty inconvenient. It would be great if the change could take place dynamically.

More specifically some sort of signal, which is emitted when a user tries to log in. The signal destination can then be a plugin for example, we call that external_service, which then verifies the user and logs him in.

The external_service itself is not part of the issue.

Impacts
Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

P.S.

My thoughts on this and a prototype implementation, which just serves testing purposes for myself can be found here: #2051

In my example I used the external_service only for the acquisition of the api_access_info and tried to reuse as much code as possible, hence I reused the login_api::login code, to avoid duplicate code. Maybe it's a good idea to make the verification also through the external_service, which would allow for custom verification schemes.

[pmconrad]

This file is loaded on startup of the node. To add a new user and make the change available, the node has to be restarted.

I think this can be improved quite easily. Check file modification time and reload upon change.

More specifically some sort of signal, which is emitted when a user tries to log in. The signal destination can then be a plugin for example, we call that external_service, which then verifies the user and logs him in.
The external_service itself is not part of the issue.

IMO we should not add arbitrary signals in the vague hope that some plugin might want to use them in the future.

Also, I think a better approach could be to install a proxy before the API port. Existing proxy implementations typically come with a variety of supported authentication schemes. A new plugin would have to re-implement this all by itself.

[Dimfred]

@xeroc tag

[xeroc]

IMO we should not add arbitrary signals in the vague hope that some plugin might want to use them in the future.

We actually have a plugin that gets credentials from SQLite (later also MySQL) databases.

Also, I think a better approach could be to install a proxy before the API port. Existing proxy implementations typically come with a variety of supported authentication schemes. A new plugin would have to re-implement this all by itself.

Bitshares-core has a login API already, why not use that? The advantage (obv) is that it doesn't break any client side implementations

[abitmore]

Also, I think a better approach could be to install a proxy before the API port. Existing proxy implementations typically come with a variety of supported authentication schemes. A new plugin would have to re-implement this all by itself.

Bitshares-core has a login API already, why not use that? The advantage (obv) is that it doesn't break any client side implementations

Because bitshares-core is harder or more expensive to extend and/or maintain. The same applies to API servers, it's clear that practically it's better to run API nodes behind a reverse proxies e.g. HAProxy or Nginx which would handle load-balancing and SSL-offloading better.

[xeroc]

Found something to work with haproxy.

Still, i think it would be a nicer solution to have it as part of plugin - after all, that's what plugins are good for, IMHO.

https://github.com/TimWolla/haproxy-auth-request