Is this IIA creation flow on macOS (storing IIA into keychain) supposed to work? (I assume so, since iCloud Keychain is an available option.). This is happening on the latest versions of macOS (12.3.1) and Safari (15.4).
Hi @lk-wilson
II dev here: we have not had the time yet to take a closer look. But it is definitely the goal to support all the major platform authentication mechanisms (including iCloud Keychain).
In the meantime, you have to use one of the other mechanisms.
Best regards
Frederik
Having given up with iCloud Keychain approach, I obtained a new Yubico C NFC security key. I’ve attempted (several times) to create an II Anchor with the Yubico key, and it fails consistently. The JavaScript console is showing an error prior to selection of the destination for passkey storage. The error is indicating it is unable to load the ic0 canister…
Fetch API cannot load https://ic0.app/api/v2/canister/rdmx6-jaaaa-aaaaa-aaadq-cai/call.
I’ve let the app run for up to 5 or 6 minutes, but it appears to not be doing anything, judging from the lack of network activity per Little Snitch network monitor.
I’ve also tried with the Yubico key plugged directly into a USB port on the back of the iMac (in case there might be a problem using an external hub), but that makes no difference.
Anybody have any recent success in creating an II anchor on macOS in Safari? Suggestions, ideas…?
What OS are you on? Have you tried Chrome as well?
I’m on Monterey and both safari & chrome work with touchID, but maybe the older versions of safari are weirder… Give it a try in Chrome / Firefox if you get a chance.
Running latest versions of everything…
macOS Monterey: 12.3.1
Safari: 15.4
Chrome: 101.0.4951.41 (Official Build) (x86_64)
I tried with Chrome, and I see the same problem. Also tried using a different computer (macBook Pro laptop) with both Safari & Chrome browsers. Same error on line 182 of index.js, where its attempting to do a fetch on a POST request to the following url:
https://ic0.app/api/v2/canister/rdmx6-jaaaa-aaaaa-aaadq-cai/call
Here’s a screen shot of the error in the Chrome browser:
Same error, same place. Two different computers, Chrome and Safari on each…
Workaround might be to create the identity on your phone for example and use touch as identification with the phone. Then, if you want to hook up your computer to the same ID you made on your phone, try to open up the II website and try using but using a new device and going through that process to add your laptop to it.
Thanks for the suggestion. I’ve tried touch ID and the yubico security key on my macBook Pro. They both result in the same error. I also tried using the touchID on my iPhone SE … it just hangs. Same story using the Chrome browser on the iPhone. I suspect the iPhone browsers are hung at the same spot as on the computers, but I can’t drop into a browser debugger to verify it.
I tried Firefox with the yubico key on my iMac, and the error message in the console says ‘Cross-Origin request blocked’ (appears to be at the same network POST request). Here’s the full set of error messages…
The documentation reference points to this page that talks about Cross-Origin Resource Sharing. Reason: CORS request did not succeed.
Firefox had no extensions enabled when I tried this, so I’m not sure what else can be changed in Firefox settings.
It looks to me like all of these network calls are being rejected by the internet-identity canister (rdmx6-jaaaa-aaaaa-aaadq-cai) for protocol or security violations of some sort.
Hey @lk-wilson!
Is this IIA creation flow on macOS (storing IIA into keychain) supposed to work? (I assume so, since iCloud Keychain is an available option.). This is happening on the latest versions of macOS (12.3.1) and Safari (15.4).
It actually works out of the box for me. As far as I can tell, “iCloud Keychain” is just the default for most people, i.e. when someone uses TouchID on (a recent) macOS, they’re actually using the “iCloud Keychain”. I’m guessing something else is not working here.
Both your Yubikey and Firefox (and Chrome) attempts suggest there’s something off with CORS (in your Yubikey attempt you had the following message, which suggests the browser blocked the request: “Fetch API cannot load https://ic0.app/api/v2/canister/rdmx6-jaaaa-aaaaa-aaadq-cai/call.”). On the other hand, on your original TouchID Safari attempt, it indeed looks like something went wrong while creating the WebAuthn credentials. Let’s focus on the CORS issue for now.
It looks to me like all of these network calls are being rejected by the internet-identity canister (rdmx6-jaaaa-aaaaa-aaadq-cai) for protocol or security violations of some sort.
Disregard what’s below, got my CORS and CSP confused
It’s actually your browser that’s blocking them. CORS works like this: when you get some HTML page (like the II webapp) the server adds some extra information like what URLs the webapp is allowed to access (for security reasons). In this case, it looks like this information is not given to your browser, and it effectively blocks requests to ic0.app.
If I visit https://identity.ic0.app, I can open the debugger/console and click “Network → index.html or identity.ic0.app → Headers” and there I’ll see the following:
Content-Security-Policy: default-src 'none';connect-src 'self' https://ic0.app;img-src 'self' data:;script-src 'sha256-lQ/P4+Qi918VotqSQiUTNX5K5IskE98oniwnRCzpoTg=' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https:;base-uri 'none';frame-ancestors 'none';form-action 'none';style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;style-src-elem 'unsafe-inline' https://fonts.googleapis.com;font-src https://fonts.gstatic.com;upgrade-insecure-requests;
Which says “you can connect to https://ic0.app”. Could you check your headers and verify you have that header as well?
@lk-wilson : Hm, you should definitely not get CORS errors.
Could you run this command from your terminal and post the result: curl -v -X OPTIONS https://identity.ic0.app/api/v2/canister/rdmx6-jaaaa-aaaaa-aaadq-cai/read_state
The result should look similar this:
* Trying 145.40.93.138:443...
* Connected to identity.ic0.app (145.40.93.138) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=boundary.dfinity.network
* start date: Mar 13 21:50:41 2022 GMT
* expire date: Jun 11 21:50:40 2022 GMT
* subjectAltName: host "identity.ic0.app" matched cert's "*.ic0.app"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f9a03010a00)
> OPTIONS /api/v2/canister/rdmx6-jaaaa-aaaaa-aaadq-cai/read_state HTTP/2
> Host: identity.ic0.app
> user-agent: curl/7.79.1
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 204
< server: nginx/1.21.3
< date: Fri, 29 Apr 2022 08:20:29 GMT
< x-ic-subnet-id: tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe
< x-ic-node-id: w7nug-ly4on-elt3f-ctsb2-3c33h-c3p3c-iy5kg-6pcjc-xhsev-bhcfd-xae
< x-ic-canister-id: 00000000000000070101
< access-control-allow-methods: GET, POST, HEAD, OPTIONS
< access-control-allow-origin: *
< access-control-allow-credentials: true
< access-control-allow-headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization
< access-control-max-age: 600
< content-type: text/plain; charset=utf-8
<
* Connection #0 to host identity.ic0.app left intact
Thanks!
Best regards
Frederik
Hi Frederik,
Here’s the output…
curl -v -X OPTIONS https://identity.ic0.app/api/v2/canister/rdmx6-jaaaa-aaaaa-aaadq-cai/read_state
* Trying 86.109.1.190:443...
* Connected to identity.ic0.app (86.109.1.190) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=boundary.dfinity.network
* start date: Mar 13 21:50:41 2022 GMT
* expire date: Jun 11 21:50:40 2022 GMT
* subjectAltName: host "identity.ic0.app" matched cert's "*.ic0.app"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f8c9d812200)
> OPTIONS /api/v2/canister/rdmx6-jaaaa-aaaaa-aaadq-cai/read_state HTTP/2
> Host: identity.ic0.app
> user-agent: curl/7.79.1
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 204
< server: nginx/1.21.3
< date: Fri, 29 Apr 2022 13:40:33 GMT
< x-ic-subnet-id: tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe
< x-ic-node-id: ue5ec-fqss7-su7nu-cbtut-wunlk-6rrtl-6agqa-gpxjs-iflqh-ax3kn-vqe
< x-ic-canister-id: 00000000000000070101
< access-control-allow-methods: GET, POST, HEAD, OPTIONS
< access-control-allow-origin: *
< access-control-allow-credentials: true
< access-control-allow-headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization
< access-control-max-age: 600
< content-type: text/plain; charset=utf-8
<
* Connection #0 to host identity.ic0.app left intact
Update: Not sure what changed overnight, but today, the registration process seems to be working for all devices. I was able to create an internet identity on my iPhone (using the fingerprint scanner), and then add the Yubico key on my iMac, and use the Yubico key to perform an II login on my both my iMac and macBookPro. I was also able to add the fingerprint scanner on my macBookPro.
1 Like
Hey @lk-wilson, thanks for the update, and glad this got resolved; The output you posted here looks OK:
Did you actually try to use II when you ran that command?
I suspect you hit a bad boundary node during some time, which either healed or was taken offline eventually. We had a few other reports (3) of similar issues, though nothing we could actually reproduce. Either way, let us know if things break again!