1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-30 08:09:15 +01:00
metamask-extension/app/scripts/controllers/permissions/restrictedMethods.js
Mark Stacey 63633635ab
Fix order of accounts in eth_accounts response (#8342)
* Fix order of accounts in `eth_accounts` response

The accounts returned by `eth_accounts` were in a fixed order - the
order in which the keyring returned them - rather than ordered with the
selected account first. The accounts returned by the `accountsChanged`
event were ordered with the selected account first, but the same order
wasn't used for `eth_accounts`.

We needed to store additional state in order to determine the correct
account order correctly on all dapps. We had only been storing the
current selected account, but since we also need to determine the
primary account per dapp (i.e. the last "selected" account among the
accounts exposed to that dapp), that wasn't enough.

A `lastSelected` property has been added to each identity in the
preferences controller to keep track of the last selected time. This
property is set to the current time (in milliseconds) whenever a new
selection is made. The accounts returned with `accountsChanged` and by
`eth_accounts` are both ordered by this property.

The `updatePermittedAccounts` function was merged with the internal
methods for responding to account selection, to keep things simpler. It
wasn't called externally anyway, so it wasn't needed in the public API.

* Remove caveat update upon change in selected account

The order of accounts in the caveat isn't meaningful, so the caveat
doesn't need to be updated when the accounts get re-ordered.

* Emit event regardless of account order

Now that we're no longer relying upon the caveat for the account order,
we also have no way of knowing if a particular account selection
resulted in a change in order or not. The notification is now emitted
whenever an exposed account is selected - even if the order stayed the
same.

The inpage provider currently caches the account order, so it can be
relied upon to ignore these redundant events. We were already emiting
redundant `accountsChanged` events in some cases anyway.
2020-04-16 15:20:01 -03:00

38 lines
1.3 KiB
JavaScript

export default function getRestrictedMethods ({ getIdentities, getKeyringAccounts }) {
return {
'eth_accounts': {
description: `View the addresses of the user's chosen accounts.`,
method: (_, res, __, end) => {
getKeyringAccounts()
.then((accounts) => {
const identities = getIdentities()
res.result = accounts
.sort((firstAddress, secondAddress) => {
if (!identities[firstAddress]) {
throw new Error(`Missing identity for address ${firstAddress}`)
} else if (!identities[secondAddress]) {
throw new Error(`Missing identity for address ${secondAddress}`)
} else if (identities[firstAddress].lastSelected === identities[secondAddress].lastSelected) {
return 0
} else if (identities[firstAddress].lastSelected === undefined) {
return 1
} else if (identities[secondAddress].lastSelected === undefined) {
return -1
}
return identities[secondAddress].lastSelected - identities[firstAddress].lastSelected
})
end()
})
.catch(
(err) => {
res.error = err
end(err)
}
)
},
},
}
}