2016-10-31 19:35:09 +01:00
|
|
|
const ethUtil = require('ethereumjs-util')
|
2017-02-21 23:25:47 +01:00
|
|
|
const normalize = require('eth-sig-util').normalize
|
2017-05-23 07:56:10 +02:00
|
|
|
const MetamaskConfig = require('../config.js')
|
|
|
|
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
|
2016-05-20 01:53:16 +02:00
|
|
|
const MAINNET_RPC = MetamaskConfig.network.mainnet
|
2017-05-16 03:05:11 +02:00
|
|
|
const ROPSTEN_RPC = MetamaskConfig.network.ropsten
|
2017-05-16 04:11:16 +02:00
|
|
|
const KOVAN_RPC = MetamaskConfig.network.kovan
|
|
|
|
const RINKEBY_RPC = MetamaskConfig.network.rinkeby
|
2016-04-12 23:41:58 +02:00
|
|
|
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
/* The config-manager is a convenience object
|
|
|
|
* wrapping a pojo-migrator.
|
|
|
|
*
|
|
|
|
* It exists mostly to allow the creation of
|
|
|
|
* convenience methods to access and persist
|
|
|
|
* particular portions of the state.
|
|
|
|
*/
|
|
|
|
module.exports = ConfigManager
|
2016-06-25 00:52:56 +02:00
|
|
|
function ConfigManager (opts) {
|
2016-04-15 22:04:17 +02:00
|
|
|
// ConfigManager is observable and will emit updates
|
|
|
|
this._subs = []
|
2017-01-12 04:04:19 +01:00
|
|
|
this.store = opts.store
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setConfig = function (config) {
|
2017-01-25 04:47:00 +01:00
|
|
|
var data = this.getData()
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
data.config = config
|
|
|
|
this.setData(data)
|
2016-04-15 22:04:17 +02:00
|
|
|
this._emitUpdates(config)
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getConfig = function () {
|
2017-01-25 04:47:00 +01:00
|
|
|
var data = this.getData()
|
2017-01-28 08:04:34 +01:00
|
|
|
return data.config
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setData = function (data) {
|
2017-01-25 04:47:00 +01:00
|
|
|
this.store.putState(data)
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getData = function () {
|
2017-01-25 04:47:00 +01:00
|
|
|
return this.store.getState()
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setWallet = function (wallet) {
|
2017-01-25 04:47:00 +01:00
|
|
|
var data = this.getData()
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
data.wallet = wallet
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-10-19 23:55:08 +02:00
|
|
|
ConfigManager.prototype.setVault = function (encryptedString) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.vault = encryptedString
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getVault = function () {
|
|
|
|
var data = this.getData()
|
2016-12-22 02:20:14 +01:00
|
|
|
return data.vault
|
2016-10-19 23:55:08 +02:00
|
|
|
}
|
|
|
|
|
2016-10-15 19:48:12 +02:00
|
|
|
ConfigManager.prototype.getKeychains = function () {
|
2017-01-25 04:47:00 +01:00
|
|
|
return this.getData().keychains || []
|
2016-10-15 19:48:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setKeychains = function (keychains) {
|
2017-01-25 04:47:00 +01:00
|
|
|
var data = this.getData()
|
2016-10-15 19:48:12 +02:00
|
|
|
data.keychains = keychains
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getSelectedAccount = function () {
|
2016-04-25 23:14:34 +02:00
|
|
|
var config = this.getConfig()
|
|
|
|
return config.selectedAccount
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setSelectedAccount = function (address) {
|
2016-04-25 23:14:34 +02:00
|
|
|
var config = this.getConfig()
|
2016-10-31 19:35:09 +01:00
|
|
|
config.selectedAccount = ethUtil.addHexPrefix(address)
|
2016-04-25 23:14:34 +02:00
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getWallet = function () {
|
2017-01-25 04:47:00 +01:00
|
|
|
return this.getData().wallet
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-03-31 19:47:40 +02:00
|
|
|
// Takes a boolean
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setShowSeedWords = function (should) {
|
2017-01-25 04:47:00 +01:00
|
|
|
var data = this.getData()
|
2016-03-31 19:47:40 +02:00
|
|
|
data.showSeedWords = should
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-10-31 19:35:09 +01:00
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getShouldShowSeedWords = function () {
|
2017-01-25 04:47:00 +01:00
|
|
|
var data = this.getData()
|
2016-03-31 19:47:40 +02:00
|
|
|
return data.showSeedWords
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-10-31 19:35:09 +01:00
|
|
|
ConfigManager.prototype.setSeedWords = function (words) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.seedWords = words
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getSeedWords = function () {
|
|
|
|
var data = this.getData()
|
2017-01-25 04:47:00 +01:00
|
|
|
return data.seedWords
|
2016-10-31 19:35:09 +01:00
|
|
|
}
|
2017-05-23 08:12:28 +02:00
|
|
|
ConfigManager.prototype.setRpcTarget = function (rpcUrl) {
|
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: 'rpc',
|
|
|
|
rpcTarget: rpcUrl,
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setProviderType = function (type) {
|
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: type,
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.useEtherscanProvider = function () {
|
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: 'etherscan',
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getProvider = function () {
|
|
|
|
var config = this.getConfig()
|
|
|
|
return config.provider
|
|
|
|
}
|
2016-10-31 19:35:09 +01:00
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getCurrentRpcAddress = function () {
|
2016-05-11 00:37:13 +02:00
|
|
|
var provider = this.getProvider()
|
|
|
|
if (!provider) return null
|
2016-06-21 22:18:32 +02:00
|
|
|
switch (provider.type) {
|
2016-05-11 00:37:13 +02:00
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
case 'mainnet':
|
|
|
|
return MAINNET_RPC
|
2016-05-11 00:37:13 +02:00
|
|
|
|
2017-05-16 03:05:11 +02:00
|
|
|
case 'ropsten':
|
|
|
|
return ROPSTEN_RPC
|
2016-05-11 00:37:13 +02:00
|
|
|
|
2017-03-22 21:00:50 +01:00
|
|
|
case 'kovan':
|
|
|
|
return KOVAN_RPC
|
2017-05-03 16:22:36 +02:00
|
|
|
|
2017-05-16 04:11:16 +02:00
|
|
|
case 'rinkeby':
|
|
|
|
return RINKEBY_RPC
|
2017-03-22 21:00:50 +01:00
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
default:
|
2017-05-16 04:11:16 +02:00
|
|
|
return provider && provider.rpcTarget ? provider.rpcTarget : RINKEBY_RPC
|
2016-06-21 22:18:32 +02:00
|
|
|
}
|
Made configuration migrateable
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-04-28 23:16:24 +02:00
|
|
|
//
|
|
|
|
// Tx
|
|
|
|
//
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getTxList = function () {
|
2017-01-25 04:47:00 +01:00
|
|
|
var data = this.getData()
|
2016-04-28 23:16:24 +02:00
|
|
|
if (data.transactions !== undefined) {
|
2016-04-19 01:39:35 +02:00
|
|
|
return data.transactions
|
|
|
|
} else {
|
|
|
|
return []
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-14 21:55:41 +01:00
|
|
|
ConfigManager.prototype.setTxList = function (txList) {
|
2017-01-25 04:47:00 +01:00
|
|
|
var data = this.getData()
|
2016-04-19 01:39:35 +02:00
|
|
|
data.transactions = txList
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-04-20 02:32:09 +02:00
|
|
|
|
2016-05-21 01:18:54 +02:00
|
|
|
// wallet nickname methods
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getWalletNicknames = function () {
|
2016-05-21 01:18:54 +02:00
|
|
|
var data = this.getData()
|
2016-06-21 22:18:32 +02:00
|
|
|
const nicknames = ('walletNicknames' in data) ? data.walletNicknames : {}
|
2016-05-21 01:18:54 +02:00
|
|
|
return nicknames
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.nicknameForWallet = function (account) {
|
2016-12-01 04:34:17 +01:00
|
|
|
const address = normalize(account)
|
2016-06-21 22:18:32 +02:00
|
|
|
const nicknames = this.getWalletNicknames()
|
2016-11-03 19:59:20 +01:00
|
|
|
return nicknames[address]
|
2016-05-21 01:18:54 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setNicknameForWallet = function (account, nickname) {
|
2016-12-01 04:34:17 +01:00
|
|
|
const address = normalize(account)
|
2016-06-21 22:18:32 +02:00
|
|
|
const nicknames = this.getWalletNicknames()
|
2016-11-03 19:59:20 +01:00
|
|
|
nicknames[address] = nickname
|
2016-05-21 01:18:54 +02:00
|
|
|
var data = this.getData()
|
|
|
|
data.walletNicknames = nicknames
|
|
|
|
this.setData(data)
|
|
|
|
}
|
2016-04-28 23:16:24 +02:00
|
|
|
|
2016-04-15 22:04:17 +02:00
|
|
|
// observable
|
|
|
|
|
2016-10-15 19:48:12 +02:00
|
|
|
ConfigManager.prototype.getSalt = function () {
|
|
|
|
var data = this.getData()
|
2017-01-25 04:47:00 +01:00
|
|
|
return data.salt
|
2016-10-15 19:48:12 +02:00
|
|
|
}
|
|
|
|
|
2016-11-11 19:26:12 +01:00
|
|
|
ConfigManager.prototype.setSalt = function (salt) {
|
2016-10-15 19:48:12 +02:00
|
|
|
var data = this.getData()
|
|
|
|
data.salt = salt
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.subscribe = function (fn) {
|
2016-04-15 22:04:17 +02:00
|
|
|
this._subs.push(fn)
|
|
|
|
var unsubscribe = this.unsubscribe.bind(this, fn)
|
|
|
|
return unsubscribe
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.unsubscribe = function (fn) {
|
2016-04-15 22:04:17 +02:00
|
|
|
var index = this._subs.indexOf(fn)
|
|
|
|
if (index !== -1) this._subs.splice(index, 1)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype._emitUpdates = function (state) {
|
|
|
|
this._subs.forEach(function (handler) {
|
2016-04-15 22:04:17 +02:00
|
|
|
handler(state)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2016-12-08 23:22:02 +01:00
|
|
|
ConfigManager.prototype.setLostAccounts = function (lostAccounts) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.lostAccounts = lostAccounts
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getLostAccounts = function () {
|
|
|
|
var data = this.getData()
|
2016-12-20 01:29:44 +01:00
|
|
|
return data.lostAccounts || []
|
2016-12-08 23:22:02 +01:00
|
|
|
}
|