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.

Sign up for GitHub

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

Jump to bottom

Custom "API ADDRESS" field communicate what the valid address is #1553

Open
Gozala opened this issue Jul 22, 2020 · 2 comments
Open

Custom "API ADDRESS" field communicate what the valid address is #1553

Gozala opened this issue Jul 22, 2020 · 2 comments
Labels
effort/days Estimated to take multiple days, but less than a week exp/intermediate Prior experience is likely helpful help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked

Comments

@Gozala
Copy link
Contributor

Gozala commented Jul 22, 2020

Per #1541 (comment) current language regarding custom API address can be misleading because:

  1. webui can not dial arbitrary addresses (e.g. https://webui.ipfs.io/ won't be able to dial any http:// address other than loopaback address.
  2. Safari can't dial any http address
  3. IPFS desktop could probably dial any address
  4. Some addresses may not provide CORS headers to allow dialing

I think we can do better by validating inputs and providing contextual information e.g.

  • Try to dial and infer why.
  • If call was blocked highlight input field and provide message saying it's not dialable.
  • If Safari is dialing and it's to localhost we could add little hint explaining that Safari doesn't comply with web standards.
  • If non safari is dialing to http other than loopback address, highlight input and provide message explaining mixed content limitation.
  • If it's to localhost or HTTPS still got blocked, message mentioning CORS headers
@Gozala Gozala added the need/triage Needs initial labeling and prioritization label Jul 22, 2020
@Gozala Gozala mentioned this issue Jul 22, 2020
Open
@jessicaschilling
Copy link
Contributor

jessicaschilling commented Jul 22, 2020 •
edited
Loading

@Gozala Is this something you have the bandwidth to take on? (In any case, can you please label the issue accordingly? Thanks!)

@Gozala
Copy link
Contributor Author

Gozala commented Jul 22, 2020

@jessicaschilling I'm afraid I still don't have privileges to assign labels. I don't think I have bandwidth right now to take on this issue.

@jessicaschilling jessicaschilling added exp/intermediate Prior experience is likely helpful effort/days Estimated to take multiple days, but less than a week help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked and removed need/triage Needs initial labeling and prioritization labels Jul 22, 2020
This was referenced Apr 3, 2021
Open
Open
@snyk-bot snyk-bot mentioned this issue Dec 14, 2021
Open
@SgtPooki SgtPooki moved this to To do in IPFS-GUI (PL EngRes) Jul 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
effort/days Estimated to take multiple days, but less than a week exp/intermediate Prior experience is likely helpful help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
No open projects
IPFS-GUI (PL EngRes)
Status: Needs Grooming
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Gozala @jessicaschilling