issue in connecting switchboard-dapp (running on localhost), with IAM-cache-server/ssi-hub (also running on localhost)

[syedmuhammaddanish]

Hi,

So basically, I have run the ssi-hub server and switchboard-dapp on the localhost on their respective ports. Now, I am trying to connect the switchboard dapp with the cache server. I am editing the environment variables in switchboard-dapp code, as shown below.

import { constants } from './constants';

// This file can be replaced during build by using the `fileReplacements` array.
// `ng build --prod` replaces `environment.ts` with `environment.prod.ts`.
// The list of file replacements can be found in `angular.json`.

export const environment = {
  production: false,
  theme: 'default',
  application: true,

  rpcUrl: 'https://volta-rpc.energyweb.org/',
  chainId: 73799,
  cacheServerUrl: 'http://localhost:3000/v1',
  natsServerUrl: 'https://identityevents-dev.energyweb.org/',
  ekcUrl: 'https://azure-proxy-server.energyweb.org/api/v1',
  kmsServerUrl: undefined,
  showAzureLoginOption: true,
  natsEnvironmentName: 'ewf-dev',
  rootNamespace: 'iam.ewc',

  fullNetworkName: 'EnergyWeb Volta Chain',
  networkName: 'Volta',
  currencyName: 'Volta Token',
  currencySymbol: 'VT',
  blockExplorerUrl: 'https://volta-explorer.energyweb.org',
  SENTRY_ENVIRONMENT: 'localhost',
  ...constants,
};

It works, and I am able to connect the switchboard-dapp to the cache server hosted locally. I can even sign in using metamask. However, the problem comes when I try to see enrollment or try to register asset. It gives error as shown below.

Moreover, I can see the transactions on volta-explorer. It actually sends the transaction to the smart contract. But the asset is never registered. Also, I feel there is a problem with the smart contract addresses. In the env file, the asset manager smart contract address is 0xE258fA7D1cc8964D0dEB7204Df947bCa42b2c940, but in volta-explorer, the transaction is being sent to the address 0x84d0c7284A869213CB047595d34d6044d9a7E14A (I digged out and got to know its identity manager contract address defined in iam-client-lib code).

Am I doing something wrong, please have a look on this issue. Thank you

[JGiter]

Hi @syedmuhammaddanish and apologize for late response

I couldn't reproduce this error. Could you please share details of failed request?
The 0x84d0c7284A869213CB047595d34d6044d9a7E14A is correct address of identity manager. ASSETS_MANAGER_ADDRESS in .env.dev is mistakenly left intact when we moved environment variables from .env files to devops folder. Sorry for confusion. We will fix this

[syedmuhammaddanish]

Hi @JGiter ,

Thank you for your reply.

So basically, the cache-server is running on http://localhost:3000/v1 on my local machine. Similarly, the switchboard application is up on http://localhost:4200.

I have changed the environment file (switchboard-dapp\src\environments\environment.ts) by defining cache-server address as localhost.

Now when I try to use switchboard-dapp, and try to login using Metamask, its fine. And you can see the output of cache-server logs below (they show switchboard-dapp is actually communicating with localhost cache-server)

But when I try to click on enrollments or assets, this is what happens in console.

I am not sure if I am missing something.

Can you please answer these questions for me?

1. Can we deploy our own smart contracts on volta testnet and use those smart contracts addresses in switchboard-dapp's and cache-server's environment ? Is it possible right now with switchboard-dapp?

2. As you said that you could not reproduce the errors, may be I am doing something wrong with configurations. Can you kindly let me know what configurations you used to connect switchboard and cache-server locally.

Your help is highly appreciated and thank you for your time.

[JGiter]

@syedmuhammaddanish To use your own contracts you can override chain configuration in

switchboard-dapp/src/app/shared/services/iam.service.ts

Line 266 in bef7107

const chainConfig: Partial<ChainConfig> = {

and in .env in cache server
I tried to reproduce error with the same configuration as you are using. The only possible incorrect value in your config is natsServerUrl, which should be the same as in docker-compose.yml in cache-server (http://localhost:9222 by default). But this is unlikely relates to your issue

It is strange that requests to did controller are allowed and to claim controller are not while all controllers are protected with the same authentication guard. Could you please share token and refreshToken cookies sent with request to http://localhost:3000/v1/claim/issuer/roles/allowed/did:ethr:volta:0xc207...

[syedmuhammaddanish]

So here is the payload being sent in the login message, which was actually approved at the start.

**General:**
Request URL: http://192.168.1.104:3000/v1/login
Request Method: POST
Status Code: 201 Created
Remote Address: 192.168.1.104:3000
Referrer Policy: strict-origin-when-cross-origin
**Response Header:**
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:4200
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Fri, 06 May 2022 15:23:36 GMT
ETag: W/"4c8-O6doOEATN2vWtK77zuIk2Sxwll8"
Expect-CT: max-age=0
Keep-Alive: timeout=5
Referrer-Policy: no-referrer
Set-Cookie: token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJkaWQiOiJkaWQ6ZXRocjp2b2x0YToweDIwN0Q2NzNEREQyMzhjMmI5MjZmQmQyMzQ1MDQ0MTYzRDBFYkJDQjMiLCJ2ZXJpZmllZFJvbGVzIjpbXSwib3JpZ2luIjoiaHR0cDovL2xvY2FsaG9zdDo0MjAwIiwiaWF0IjoxNjUxODUwNjE2LCJleHAiOjE2NTE4NTE4MTZ9.nfsrTeh-u3nBlHJuhKQpg2VOzKuVcO3HJfAADbAXSeK-lnZuqwkEDpfMed2bWTlWQ3JXLBrRijO-GHDLe8w1F0iJnlyYV0CwANigEvtiMyZREhO0m9Ov8KgaeNYwPBFGbad5cKKuLxqY87PwnIFiL-99Fs_w6VNRl41FKgkgpV-S49hqjyZf4RF6n6hivyPySn8GBz_xmkFZsKuY2MFpBhSFcQTUyyqgn5IcpztxTAVZDOR5uhOxU1QiLY9FjERPiCtVTTI8vdhhg_KtI0nQoAytQbHwK7_pT3Uy5Eo5phRHrqUbRyZ3hk5b5SzZj4nj9Al5-1GQ1POvS5ykiF7Kuw; Path=/; HttpOnly; SameSite=Strict
Set-Cookie: refreshToken=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbklkIjoiNTE2YWMwZmUtMjc1Ny00OTk1LWJiZjgtZjhmOTk0NmFmODY5IiwiaXNSZXZva2VkIjpmYWxzZSwidXNlckRpZCI6ImRpZDpldGhyOnZvbHRhOjB4MjA3RDY3M0RERDIzOGMyYjkyNmZCZDIzNDUwNDQxNjNEMEViQkNCMyIsImlhdCI6MTY1MTg1MDYxNiwiZXhwIjoxNjUxODUxODE2fQ.ApRiqL5p-KOx-XggO9XO65tUzEbx_b1RF81Rd3Ygx5ru2iFcaIlQtCAUifsVjRYp9Trz1WFNSJlW8PB6HC60_tdLuyF0sJz-lmpQ9JtDCH4JSR6Fy6po_Cy1tTIT6rWi67JWHdQtUXgRRC0srWb4VevVEN8UGf97g_jaVGioqnMQAy5hfGBOuMR_GYcx9ifzsVHguQk5TNJsQyabTabiq2lBGNWBG28fxY7GpkQmT02--FyUJjjAaW3REzBWl9hQLezkwyjsCumcPdnJVWyJsNBPc-ieon77-oNprg5rcYcwUaSjMCSRXpBeWVD2ytgPiEF0cL9laq0sie-WbrdT4w; Path=/; HttpOnly; SameSite=Strict
Strict-Transport-Security: max-age=15552000; includeSubDomains
Transfer-Encoding: chunked
Vary: Origin, Accept-Encoding
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 0
**Request Header:**
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,la;q=0.8,fr;q=0.7
Connection: keep-alive
Content-Length: 373
Content-Type: application/json
Host: 192.168.1.104:3000
Origin: http://localhost:4200
Referer: http://localhost:4200/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.54 Safari/537.36

While requesting http://localhost:3000/v1/claim/issuer/roles/allowed/did:ethr:volta:0xc207...,

This is what i found in console.

**General**
Request URL: http://192.168.1.104:3000/v1/claim/issuer/roles/allowed/did:ethr:volta:0x207D673DDD238c2b926fBd2345044163D0EbBCB3
Request Method: GET
Status Code: 401 Unauthorized
Remote Address: 192.168.1.104:3000
Referrer Policy: strict-origin-when-cross-origin
**Response Header:**
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:4200
Connection: keep-alive
Content-Length: 66
Content-Type: application/json; charset=utf-8
Date: Fri, 06 May 2022 15:23:36 GMT
ETag: W/"42-qzEeNmfl7/Oz/7NrS0aSp2IBTls"
Expect-CT: max-age=0
Keep-Alive: timeout=5
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=15552000; includeSubDomains
Vary: Origin, Accept-Encoding
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 0
**Request Header:**
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,la;q=0.8,fr;q=0.7
Connection: keep-alive
Host: 192.168.1.104:3000
Origin: http://localhost:4200
Referer: http://localhost:4200/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.54 Safari/537.36

Also, I have changed the cooker.service.ts file in ssi-hub code as per this

Note that when running in dev, you can change the cookie policy in cookies.service.ts from

sameSite: 'none',
secure: true
to

sameSite: 'strict',
secure: false,

In this way, an app hosted on localhost (assuming the cache-server is also served on localhost) will store the authentication cookies even if the requests aren't sent over a secure connection.

[JGiter]

@syedmuhammaddanish Are there any cookies sent with request to issuer/roles/allowed? They must be the same token and refreshToken which were received from login. Could you verify that the same cookies are in successful requests like to DID/did:ethr:volta:0xc207...
Also could you share .env of ssi-hub?

[syedmuhammaddanish]

@JGiter , I tried to look into the payload and no cookies are being sent to the server with the request. Infact with every request I am making on switchboard-dapp.

Here is my .env file

# NESTJS CONFIG
NESTJS_PORT=3000

# DB Config
DB_HOST=postgres
DB_PORT=5432
DB_USERNAME=postgres
DB_PASSWORD=password
DB_NAME=dev-test

# Redis
REDIS_VERSION=6.0.8
REDIS_PASSWORD=password
REDIS_PORT=6379
REDIS_HOST=redis

#NATS.IO CONFIG
NATS_VERSION=2.1.8
NATS_CLIENTS_URL=nats:4222
NATS_ENVIRONMENT_NAME=dev

# ENS
CHAIN_ID=73799
CHAIN_NAME=volta
ENS_URL=https://volta-rpc.energyweb.org
PUBLIC_RESOLVER_ADDRESS=0x0a97e07c4Df22e2e31872F20C5BE191D5EFc4680
ENS_REGISTRY_ADDRESS=0xd7CeF70Ba7efc2035256d828d5287e2D285CD1ac
DID_REGISTRY_ADDRESS=0xc15d5a57a8eb0e1dcbe5d88b8f9a82017e5cc4af
CLAIM_MANAGER_ADDRESS=0x2F259e307D0Ba78902391c070e7b4aA043E74DBB
DOMAIN_NOTIFIER_ADDRESS=0xeea658026d6CDede4380D3aD030beAC911758A93
STAKING_POOL_FACTORY_ADDRESS=0x4b2A127680320eD980beAa7aD9b2447B96BC32fC
RESOLVER_V1_ADDRESS=0xf5EA22c1F799d425356c2aab2004200Ab4490D2b

# ASSETS 
#ASSETS_MANAGER_ADDRESS=0x38cF23C52Bb4B13F051Aec09580a2dE845a7FA35
ASSETS_MANAGER_ADDRESS=0x84d0c7284A869213CB047595d34d6044d9a7E14A
ASSETS_SYNC_INTERVAL_IN_HOURS=10
ASSETS_SYNC_HISTORY_INTERVAL_IN_HOURS=21
ASSETS_SYNC_ENABLED=true

# IPFS
IPFS_URL=https://ipfs.infura.io:5001/api/v0/

# INTERVALS
DIDDOC_SYNC_INTERVAL_IN_HOURS=1
DID_SYNC_MAX_CONCURRENT=2
DID_SYNC_ENABLED=false
ENS_SYNC_INTERVAL_IN_HOURS=1
ENS_SYNC_ENABLED=false
DID_SYNC_MODE_FULL=false

# AWS ECR
DOCKER_REGISTRY=
DOCKER_REPOSITORY=
DOCKER_TAG=

# AUTH
ENABLE_AUTH=true
JWT_PRIVATE_KEY=private.pem
JWT_PUBLIC_KEY=public.pem
STRATEGY_CACHE_SERVER=http://localhost:3000/v1/
STRATEGY_PRIVATE_KEY=3d3726d83996f8335cb8971b1dfbb1ff2f915f1fda84c1be99fa471764a2e5ef
STRATEGY_NUM_BLOCKS_BACK=10
JWT_ACCESS_TOKEN_EXPIRES_IN=20m
JWT_REFRESH_TOKEN_EXPIRES_IN=20m
JWT_ACCESS_TOKEN_NAME=token
JWT_REFRESH_TOKEN_NAME=refreshToken

# DID UNIVERSAL RESOLVER
UNIVERSAL_RESOLVER_URL=https://dev.uniresolver.io/1.0/identifiers/

# SENTRY CONFIG
SENTRY_DNS=
SENTRY_ENV=
SENTRY_RELEASE=

[JGiter]

So even requests sent right after login doesn't have cookies? Like this

[syedmuhammaddanish]

Yes you are right.

No cookies are being sent with the request.

However, cookies are being generated in the login request as shown below.

[JGiter]

I can see that claim request are sent to https://192..., instead of localhost. Perhaps the cache server url in environment.ts has somehow been changed. Also which domain cookies belongs to?

[syedmuhammaddanish]

This 192.... ip address belongs to my windows machine and the cache-server is being run on linux VM with its own local host. I am communicating with linux VM from my windows pc through this IP address.