Skip to main content

Troubleshooting Guide


Configuration Issues


Cannot change storage region from North America to Europe

Storage region setting is a one time configuration.

You can register your dApp using the Arcana Developer Dashboard:

https://dashboard.beta.arcana.network

When you visit the portal for the first time and register your dApp, you will be asked to choose a storage region or keep the default setting. The only way to change the storage region is to delete the dApp from the dashboard and configure afresh.

Once you start using your dApp and users store some data in the Arcana Store, you can always reconfigure the dApp using the dashboard for user storage limit values or enabling / disabling social authentication providers. However, storage region, once set, cannot be altered.

Cannot turn off UI for wallet mode

Arcana dashboard allows dApp developers to manage the user experience for signing blockchain transactions pertaining to user data storage operations. This is controlled using the WALLET UI setting in the Auth tab of the dashboard.

By default, WALLET UI mode is set to Disabled. What this means is there will be no pop up UI that requires the user to sign every file storage access operation (share, delete, revoke access, change owner). In this case, the end user experience is very similar to the typical Web2 applications without losing on any security or benefits of blockchain.

Once the UI mode is enabled using the dashboard setting, it cannot be disabled later or reconfigured due to security reasons.

Besides the dashboard setting, there is another control that works in tandem with the dashboard setting to tweak the blockchain transaction signing behavior.

The dApp developer can choose appMode during Auth SDK initialization function call. Once WALLET UI setting is enabled through the dashboard, the dApp developer can use appMode in the dApp code when integrating with the Auth SDK. The appMode parameter in the Auth SDK initialization function controls the popup UI type configuration that shows up for dApp users.

Typically, once coded in the dApp it should not be changed. See wallet mode for details on how different appMode choices can control popup UI behavior and user experience for blockchain transaction signing.

For step by step instructions see how to configure Wallet UI guide.

Aggregate login does not work with GitHub

Scenario

Developer logs into the Arcana Dashboard using social authentication provider P1. For the very first login, the dashboard brings up 'create new dApp' workflow allowing the developer to register a new dApp and obtain a unique appID say ID1. Now if the developer logs out and logs back in using a different social authentication provider P2, Arcana Network can recognize that the login is by the same developer so it brings up the 'monitor dashboard' screen for appID=ID1 that was earlier registered by this same developer. This happens provided the developer has the same email ID associated with both providers P1 and P2.

If the user has a different email ID associated with providers P1 and P2 then during the second login using a different provider, the same developer cannot be recognized and associated with the developer that registered the appID=ID1. The dashboard considers login with a new provider (different email ID) as a new identity and assumes this is a fresh login by a new developer. It brings up 'create new dApp' workflow allowing this 'new' developer to register the dApp.

If one of the provider is GitHub, then even if the same email ID is associated with all providers, Arcana Network may fail to associate GitHub identity of the same developer with other providers. Instead of bringing up the 'monitor dashboard' for appID=ID1, it brings up the first login specific workflow, 'create new dApp' and expects the same user to register a new dApp.

How can a developer make sure that Arcana Network can successfully associate the GitHub account of a developer with other social authentication providers, if same email ID is used in every provider account?

Solution

The aggregate login feature of Arcana Network allows a dApp developer to login into the dashboard using any supported social authentication mechanism and register and configure their dApp. The same dApp is associated with multiple social accounts that the developer uses to login. This feature works only if the developer has the exact same email ID associated with all the social OAuth providers. This allows Arcana Network to recognize the developer irrespective of any social OAuth used to login into the dashboard. What this means is, every time this developer logs into the dashboard, (s)he will be able to see the same dApp that is configured by them.

With GitHub, the behavior is different, only if the GitHub user settings are not in place. To ensure the same behavior as other social authentication providers in case of GitHub, make sure that you specify the following details in GitHub Settings:

  1. In your GitHub profile setting, allow your email to be visible
  2. In the GitHub Email Settings preferences, make sure you do not select the checkbox which says 'Keep my email address private'.

Refer to figure below for details:

GitHub Profile email visible GitHub Email Settings not private


dApp Tooling Issues


Failed to integrate with Arcana SDK due to polyfill issues

Polyfill errors are often encountered by a vast majority of web3 libraries and applications using node.js libraries. These are often reported in stackoverflow and in the context of Vite.

The polyfilling issues result in developers not being able to import the Arcana SDKs at all in their dApps. Bundlers complain or otherwise you may see runtime errors as shown in the example below.

If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "os": require.resolve("os-browserify/browser") }'
- install 'os-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "os": false }
@ ./src/config.ts 5:0-28 8:0-13
@ ./src/index.tsx 17:0-66 27:19-27 29:23-43 30:23-43 34:35-60

While integrating with Arcana SDKs, if your dApp encounters similar polyfill errors while using bundlers such as Vue-CLI, or CRA, follow these steps to fix them. Other bundlers or toolchains may require their own solutions. Some toolchains may do this by default and require no further modification. You can also refer to sample code for details.

Vue-CLI

With Vue-CLI it’s relatively easy to address polyfill issues. Simply add “node-polyfill-webpack-plugin” and that’s all you need.

const { defineConfig } = require('@vue/cli-service')
const NodePolyfillPlugin = require('node-polyfill-webpack-plugin')

module.exports = defineConfig({
configureWebpack: {
plugins: [
new NodePolyfillPlugin()
]
}
})

CRA

CRA by default doesn’t allow customizing Webpack configuration. The recommended way to address polyfill issues is to use “react-app-rewired” with a configuration like this.

note

You need to exclude “console” otherwise it’ll fail.

const NodePolyfillPlugin = require('node-polyfill-webpack-plugin')

module.exports = {
webpack: (config, env) => {
config.plugins.push(new NodePolyfillPlugin({
excludeAliases: ['console']
}))
return config
}
}

Vite

Besides installing all the required poly-fills, Vite can enable poly-fills per dependency as shown below:

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

import { NodeGlobalsPolyfillPlugin } from '@esbuild-plugins/node-globals-polyfill'
import { NodeModulesPolyfillPlugin } from '@esbuild-plugins/node-modules-polyfill'
import rollupNodePolyFill from 'rollup-plugin-polyfill-node'

// https://vitejs.dev/config/
export default defineConfig({
plugins: [vue()],
resolve: {
alias: {
// This Rollup aliases are extracted from @esbuild-plugins/node-modules-polyfill,
// see https://github.com/remorses/esbuild-plugins/blob/master/node-modules-polyfill/src/polyfills.ts
// process and buffer are excluded because already managed
// by node-globals-polyfill
util: 'rollup-plugin-polyfill-node/polyfills/util',
sys: 'util',
events: 'rollup-plugin-polyfill-node/polyfills/events',
stream: 'rollup-plugin-polyfill-node/polyfills/stream',
path: 'rollup-plugin-polyfill-node/polyfills/path',
querystring: 'rollup-plugin-polyfill-node/polyfills/qs',
punycode: 'rollup-plugin-polyfill-node/polyfills/punycode',
url: 'rollup-plugin-polyfill-node/polyfills/url',
http: 'rollup-plugin-polyfill-node/polyfills/http',
https: 'rollup-plugin-polyfill-node/polyfills/http',
os: 'rollup-plugin-polyfill-node/polyfills/os',
assert: 'rollup-plugin-polyfill-node/polyfills/assert',
constants: 'rollup-plugin-polyfill-node/polyfills/constants',
_stream_duplex:
'rollup-plugin-polyfill-node/polyfills/readable-stream/duplex',
_stream_passthrough:
'rollup-plugin-polyfill-node/polyfills/readable-stream/passthrough',
_stream_readable:
'rollup-plugin-polyfill-node/polyfills/readable-stream/readable',
_stream_writable:
'rollup-plugin-polyfill-node/polyfills/readable-stream/writable',
_stream_transform:
'rollup-plugin-polyfill-node/polyfills/readable-stream/transform',
timers: 'rollup-plugin-polyfill-node/polyfills/timers',
console: 'rollup-plugin-polyfill-node/polyfills/console',
vm: 'rollup-plugin-polyfill-node/polyfills/vm',
zlib: 'rollup-plugin-polyfill-node/polyfills/zlib',
tty: 'rollup-plugin-polyfill-node/polyfills/tty',
domain: 'rollup-plugin-polyfill-node/polyfills/domain'
}
},
optimizeDeps: {
esbuildOptions: {
// Node.js global to browser globalThis
define: {
global: 'globalThis'
},
// Enable esbuild polyfill plugins
plugins: [
NodeGlobalsPolyfillPlugin({
process: true,
buffer: true
}),
NodeModulesPolyfillPlugin()
]
}
},
build: {
rollupOptions: {
plugins: [
// Enable rollup polyfills plugin
// used during production bundling
rollupNodePolyFill()
]
}
}
})
caution

The vite configuration example above demonstrates a generic configuration that covers all libraries. You need to specify only the ones that are referred to by your dApp.

Make sure you update the dependency for polyfills in package.json file as well. Here is an example of a package.json file:

{
"name": "test-vite-app",
"private": true,
"version": "0.0.0",
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"dependencies": {
"@arcana/storage": "https://testnet-dev.s3.dualstack.ap-south-1.amazonaws.com/storage-1654680842-1e5926ffe590fad67d03aa149673f94e43f0773b9130374f306d37ea.tar",
"vue": "^3.2.25"
},
"devDependencies": {
"@esbuild-plugins/node-globals-polyfill": "^0.1.1",
"@esbuild-plugins/node-modules-polyfill": "^0.1.4",
"@vitejs/plugin-vue": "^2.3.3",
"crypto-browserify": "^3.12.0",
"rollup-plugin-polyfill-node": "^0.9.0",
"string_decoder": "^1.3.0",
"vite": "^2.9.9"
}
}

For a complete sample app that addresses polyfill issues - refer to sources in GitHub.


SDK Integration Issues


Storage SDK requires appID for integration, where do I get an appID?

Before you can integrate your dApp with Arcana Auth or Storage SDK, you need to register and configure your dApp through the developer dashboard:

https://dashboard.beta.arcana.network

As part of registration, you will be asked to login into the dashboard using any of the supported mechanisms and specify your dApp name:

  • Google
  • Discord
  • Twitter
  • GitHub

You can choose to not change any default settings and simply register your app. As part of the dApp registrations, an appID is assigned to your dApp. It is displayed against your dApp on the dashboard.

You can revisit the developer dashboard and refer to your dApp appID anytime.

note

Once your dApp is registered and assigned an appID, it does not change. If you delete your dApp from the dashboard and register it afresh, you may or may not be assigned the same appID.


Storage Issues


Storage Issue Description with proper keywords

note

This is work in progress.

Contact Us

If you do not find your issue listed in this guide or mentioned as an open issue at Arcana GitHub Repositories, please create a new issue or write to us at:

📨 support@arcana.network