Verify Eth Signature

Why do you need to verify the signature if you already know the address of the user (by accepting the Connect Request)?

By verifying the signature, you are verifying that that person owns the address.
If you didn’t, then anyone could pick any address, make up any message, and log in to someone else’s account.

How can I host the Verify Eth Signature on my server?

It runs on JavaScript, so first off, make sure you have Node installed. On Linux, you can install it with apt install nodejs.
Then download the source from https://gitlab.com/losnappas/verify-eth-signature.

Then go into the folder and type npm install to install the dependencies. I think npm is included with nodejs, but if it isn’t, apt install npm.
Now you’re ready to run it, so run npm start in the folder, and you’ve now got it running on port 5000.

Next you need to change the api_url. Since there’s no options page yet, you have to do it manually. Here’s the code (you can remove it after you run it once):

$opt = get_option('ethpress');
$opt['api_url'] = 'https://localhost:5000/ethpress';
update_option('ethpress', $opt);

You might have to change “localhost” to your url, but might not.
‘https://verify-eth-signature.herokuapp.com/ethpress’ is the default, if you want to go back.

Will it be possible to use WP REST API?

What do you mean? So that page doesn’t reload after login? I haven’t done anything to make it work like that, so I don’t think it will. In the future, hopefully.

If in future I want to swap to another plugin, users will not be able to login anymore on their profiles (because signature verification will be different)?

The signature creation/verification is a feature of Ethereum wallets, so it doesn’t matter.

Basically, every time you login, there is a new message created by server, signed by user, & verified by server, and each time proving that you own that address, so we let you log in to that address.

However, you’d most likely need to do some work on your database to make it work with the other plugin, so it’s not like you just jump between them every day.

Right now there’s a table with (address, userID) and when you verify (address) you get signed into (userID), so that’s how that works.

Ok thanks,
how can I limit requests from my domains only?
what’s the file to edit to change the api_url?

Right now there’s a table with (address, userID) and when you verify (address) you get signed into (userID), so that’s how that works.

So even if an user changes his username he will still be able to login because the plugin looks for userid instead of user_login?

how can I limit requests from my domains only?

From https://codesquery.com/enable-cors-nodejs-express-app/ it looks like

const cors = require('cors');

const app = express();

app.use(cors({
  origin: 'https://alloweddomain.com'
}));

is how you do it. Run npm install cors and add the require('cors') line and the app.use... part into index.js of verify-eth-signature, and then npm start and you’re good.

what’s the file to edit to change the api_url?

Put that code in your functions.php and load any page and it should work fine. Then you can remove the code. You could edit the database directly, if that’s easier. Find the ‘ethpress’ key in ‘{prefix}options’ and simply edit the url.

So even if an user changes his username he will still be able to login because the plugin looks for userid instead of user_login?

Well, I haven’t tested that, but sounds like it should work. However, shouldn’t users be changing their “nicknames” rather than “usernames”~?

• This reply was modified 5 years, 6 months ago by lynn999.

Thanks for all the infos!

Right now there’s a table with (address, userID) and when you verify (address) you get signed into (userID), so that’s how that works.

Why do you need this table? You cant simply search for users with that ETH address as username (since usernames are unique)?

Hi,

You sure could. But I had this idea that I’d let people associate more addresses per account, or associate an address to an already existing account, so I had to make a table. I haven’t gotten around to making this a reality, yet.

Initially I had used the nonce implementation (featured in the TopTal post linked on the plugin home page), so that one needed the table as well. I scrapped that later, but the table stayed.

Newer version (not yet the default), 0.3.0, has an options page: https://www.ads-software.com/plugins/ethpress/advanced/, if you’d like to test.

In version 0.4.1, the options page has a setting for so you can more easily set the URL of the verification service.

Marking as resolved, but do give feedback if you find the opportunity.