nNON
February 15, 2023, 8:40pm
1
After calling compose.setDID(did) when making requests with compose.executeQuery it returns the follow error:
The compose.did object:
After the recent update on composedb/devtools this seems to be an issue with gql auth.
Versions:
“@composedb /devtools”: “^0.3.0”,
“@composedb /devtools-node”: “^0.3.1”,
“@composedb /cli/0.3.1 darwin-arm64 node-v16.15.1 (the local bin)”
spencer
February 15, 2023, 10:22pm
2
You might have to call an authenticate
method, on either the DID or the compose instance?
nNON
February 15, 2023, 10:54pm
3
export const generateSession = async () => {
const compose = useStore.getState().compose
try {
const keys = await setScanVariables()
const { address, slot } = keys[0]
const resources = compose.resources
const authMethod = await loadAuthMethod(address, slot)
const session = await DIDSession.authorize(authMethod, { resources })
localStorage.setItem('didsession', session.serialize())
compose.setDID(session.did)
return session
} catch (err) {
return null
}
}
loadAuthMethod
Before it would authenticate with DIDSession.authorize but not sure why it isn’t now. Where should I call authenticate when using DIDSession?
spencer
February 16, 2023, 3:52am
4
Tagging in @zfer to take a look at the authentication issue
1 Like
nNON
February 21, 2023, 7:33pm
5
@zfer @spencer
Ok I seem to have figured out the problem. But it introduces a new problem. On a previous version of composedb I’ve used
export const compose = new ComposeClient({ ceramic: 'http://localhost:7007', definition })
But my requirement is using a staging url: https://staging.com:7007 . In the past I had to refactor composedb/devtools-node to bypass cors. It doesn’t seem to be throwing an error this time. But compose doesn’t get initialized. Is it silently failing because of cors?
nNON
February 22, 2023, 7:57pm
6
Any idea why this is happening?
nNON
February 22, 2023, 8:29pm
7
loadSession had some logic incorrectly commented out.
1 Like