-
Notifications
You must be signed in to change notification settings - Fork 29
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
HTTPS endpoint for IPFS HTTP API #139
Comments
BTW that is also a primary reason why I end up needing a my custom server in PoC, otherwise I could just leverage daemon. |
Just for the record, if there is no other option to support Safari we could do this TLS dance only on Mac. Relevant excerpts from discussion after #137 (comment):
|
@lidel I have being doing more digging into this and there some good news:
|
"potentially trustworthy" problem will most likely be tackled as part of |
Unfortunately safari blocks requests to http://127.0.0.1 I was hoping they would eventually start treating it as potentially trustworthy eventually but even last technology preview seems to block it. Which means HTTPS sites are unable to talk to local daemon through HTTP API.
I would like to suggest to use idea implemented in my PoC:
https://github.com/Gozala/lunet/tree/25d0ab4231d5591a14ece75044fa0ed245fde026#srclocal
Note: On first run daemon can generate self signed certificate and add to a locally trusted roots on the system. Daemon could listen on say
5002
port along side of5001
and serve it over HTTPS with that certificate. This setup works fine on Safari and Chrome, although not in Firefox, however Firefox and Chrome both treathttp://127.0.0.1
as potentially trustworthy (although there is a bug in Firefox when doing so in SW, but we can fix that) which is to say you could cover all major browsers by tryinghttp://127.0.0.1:5001
and then by falling back tohttps://127.0.0.1:5002
.The text was updated successfully, but these errors were encountered: