Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

access-client Agent.url defaults to HOST even when custom connection is used #344

Closed
natevw opened this issue Jan 14, 2023 · 0 comments · Fixed by #440
Closed

access-client Agent.url defaults to HOST even when custom connection is used #344

natevw opened this issue Jan 14, 2023 · 0 comments · Fixed by #440
Milestone

Comments

@natevw
Copy link
Contributor

natevw commented Jan 14, 2023

I am having trouble connecting to a locally-hosted API from the web3ui KeyringProvider. I have been able to switch the URL so that the email validation HTTP POST / goes to my configured http://localhost:8787 URL. But the /validate-ws WebSocket connection continues connecting to the default https://access.web3.storage where it doesn't receive the (local) successful delegation message.

I believe the code at https://github.com/web3-storage/w3protocol/blob/27f2f60dac7c95cb9efd42a28f5abfef8bdeb197/packages/access-client/src/agent.js#L82 might be incorrect?

Based on its usage in…

…it seems that the assignment should probably fallback first to the connection's URL before jumping straight to using the default. I.e. something like:

this.url = options.connection?.url ?? options.url ?? new URL(HOST) 

so that if a connection is provided its URL is used, otherwise falling back to an auto-created connection. Does that match the intent of the connection vs. url options, or would there ever be a use case to have an Agent.url mismatched versus the Agent.connection.url?


Background to reproduce:

Using the tips from https://filecoinproject.slack.com/archives/C02BZPRS9HP/p1669658502951759?thread_ts=1669658366.189139&cid=C02BZPRS9HP, I have added a file retaining the "staging-service.js" name for simplicity, although this is pointing at a local service instead:

import { connect } from '@ucanto/client'
import { CAR, CBOR, HTTP } from '@ucanto/transport'
import * as DID from '@ipld/dag-ucan/did'

DID.parse('did:key:z6MkwTYX2JHHd8bmaEuDdS1LJjrpFspirjDcQ4DvAiDP49Gm')
export const accessServiceURL = new URL('http://localhost:8787')
export const accessServicePrincipal = DID.parse('did:web:local.web3.storage')

export const accessServiceConnection = connect({
  id: accessServicePrincipal,
  encoder: CAR,
  decoder: CBOR,
  channel: HTTP.open({
    url: accessServiceURL,
    method: 'POST'
  })
})

Which I put as a sibling and use from "w3ui/examples/react/sign-up-in/src/App.jsx" by adding/changing the lines:

import { accessServicePrincipal, accessServiceConnection } from './staging-service.js'

//…

<KeyringProvider servicePrincipal={accessServicePrincipal} connection={accessServiceConnection}>
nate-dag pushed a commit to natevw/w3ui that referenced this issue Jan 14, 2023
nate-dag pushed a commit to natevw/w3protocol that referenced this issue Jan 27, 2023
this is one way of resolving issue storacha-network#344, where a custom server URL is used only for the individual HTTP requests and not for the corresponding WebSocket connection
nate-dag pushed a commit to natevw/w3protocol that referenced this issue Jan 31, 2023
this is one way of resolving issue storacha-network#344, where a custom server URL is used only for the individual HTTP requests and not for the corresponding WebSocket connection
@heyjay44 heyjay44 added this to the w3up phase 3 milestone Feb 16, 2023
@heyjay44 heyjay44 linked a pull request Feb 16, 2023 that will close this issue
@heyjay44 heyjay44 mentioned this issue Feb 16, 2023
83 tasks
travis added a commit that referenced this issue Feb 21, 2023
This fixes #344 and makes it possible to connect to staging services with w3ui.

This PR obsoletes #404 per @alanshaw's suggestion in #404 (comment) based on reasoning in web3-storage/ucanto#214 (comment) which points out that some sort of conditional or casting is probably unavoidable here.

My solution casts the channel to have an optional `url` field and looks in that field for a URL before falling back to the default `HOST`.
travis added a commit that referenced this issue Feb 21, 2023
This fixes #344 and
makes it possible to connect to staging services with w3ui.

This PR obsoletes #404
per @alanshaw's suggestion in
#404 (comment)
based on reasoning in
web3-storage/ucanto#214 (comment)
which points out that some sort of conditional or casting is probably
unavoidable here.

My solution casts the channel to have an optional `url` field and looks
in that field for a URL before falling back to the default `HOST`.

Have tested this locally with w3ui and verified it makes it possible to
connect to staging services from w3ui - huzzah!
travis added a commit to storacha-network/w3ui that referenced this issue Feb 21, 2023
this integrates the fix to storacha-network/w3up#344 and enables working against staging services from this library
travis added a commit to storacha-network/w3ui that referenced this issue Feb 22, 2023
this integrates the fix to
storacha-network/w3up#344 and enables
working against staging services from this library
gobengo pushed a commit that referenced this issue Apr 11, 2023
This fixes #344 and
makes it possible to connect to staging services with w3ui.

This PR obsoletes #404
per @alanshaw's suggestion in
#404 (comment)
based on reasoning in
web3-storage/ucanto#214 (comment)
which points out that some sort of conditional or casting is probably
unavoidable here.

My solution casts the channel to have an optional `url` field and looks
in that field for a URL before falling back to the default `HOST`.

Have tested this locally with w3ui and verified it makes it possible to
connect to staging services from w3ui - huzzah!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants