-
Notifications
You must be signed in to change notification settings - Fork 22
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
Milestone
Comments
nate-dag
pushed a commit
to natevw/w3ui
that referenced
this issue
Jan 14, 2023
this includes a hasty workaround for storacha/w3up#344
nate-dag
pushed a commit
to natevw/w3protocol
that referenced
this issue
Jan 27, 2023
this is one way of resolving issue storacha#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#344, where a custom server URL is used only for the individual HTTP requests and not for the corresponding WebSocket connection
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 storacha/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 storacha/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/w3ui
that referenced
this issue
Feb 21, 2023
this integrates the fix to storacha/w3up#344 and enables working against staging services from this library
travis
added a commit
to storacha/w3ui
that referenced
this issue
Feb 22, 2023
this integrates the fix to storacha/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 storacha/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!
Peeja
pushed a commit
to storacha/upload-service
that referenced
this issue
Jan 29, 2025
this integrates the fix to storacha#344 and enables working against staging services from this library
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 HTTPPOST /
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:
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 anAgent.url
mismatched versus theAgent.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:
Which I put as a sibling and use from "w3ui/examples/react/sign-up-in/src/App.jsx" by adding/changing the lines:
The text was updated successfully, but these errors were encountered: