search

bitshares / bitshares-core

BitShares Blockchain node and command-line wallet
https://bitshares.github.io/
Other
1.17k stars 647 forks source link

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

Open Dimfred opened 4 years ago

Dimfred commented 4 years ago

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.

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 commented 4 years ago

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 commented 4 years ago

@xeroc tag

xeroc commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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