Hacker Newsnew | past | comments | ask | show | jobs | submit | jtcasper's commentslogin

The <datalist> element with a text input field is an HTML native typeahead, which works great with SSR or you could wire up the datalist client side with an XHR creating the datalist.

You maybe don't get full control over the rendering style of it, but it's a still significantly more usable than the Angular Material autocompletes.


That's an interesting one I wasn't familiar with.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

It's a shame clicking on it doesn't show the options like a select box though.


Click again I guess?

> Recommended values in types text, search, url, tel, email and number, are displayed in a drop-down menu when user clicks or double-clicks on the control.


Clicking it shows the options for me (Chrome 119).


On paper, <datalist> is great but as implemented (or not) in all browsers, it has issues. This post walks through an example of using the element but also summarizes issues (as of June 2023): Under-Engineered Comboboxen?

https://adrianroselli.com/2023/06/under-engineered-comboboxe...


<input> with <datalist> still doesen't work on Firefox Android.


My Solokey is hackable and firmware available under Apache/MIT (https://github.com/solokeys/solo1).

Unfortunately the easiest way to "export" is likely to rely on the RP, as if they effectively use the sign_counter they may flag such a key as cloned. They should ideally just let you register multiple (and that's an RFC 'SHOULD').

Not a shill by the way, just a happy solokey owner.


FIDO2/WebAuthn don't have anything to do with user management from an application architecture perspective. They leave all the work of combining the attestation credentials and your application's concept of a "user" to the application.

This means you can (and should as a designer) have multiple sets of credentials for one "user", multiple distinct credentials that you (the user) can register to multiple separate "user"s in the application, etc.

I believe all FIDO2 authenticators (like hardware keys) should generate a new hardware / key ID for each request for pairing a new credential. I know that my key does that, when I was working on implementing WebAuthn for $DAYJOB.

https://developers.yubico.com/WebAuthn/ is a good jumping off point.


I think we found out about it in October or November from a pre-release Chromium Edge user? I definitely was surprised to see as short a turnaround as 5-6 months, and if you're only hearing about it now I can't imagine the stress.

I was lucky to have some time to work on it and get it done before the holidays so I didn't have to worry too much. I wrote up a migration blog post and commented it here as well because I know I wanted that kind of resource when I was working on it, so if anyone needs that I hope it helps.


I just migrated our auth service for my employer and wrote up a guide on what I think you need to know and should do if you're going through it. I think it was overall incredibly straightforward, and the Yubico maintainers even added some additional functionality to their Java server-side library as I corresponded with them.

To plug myself a bit, hopefully this can be helpful to others, and I'd appreciate feedback if you find it unclear: https://www.jacobcasper.com/u2f2webauthn.html


Why bother writing a webserver when you can have systemd BE the webserver? I use the SQLite database as a standin for something heavy like Kafka, because I need to guarantee all messages are delivered and uploaded before I stop attempting to upload them again. Currently have this running on a nanode instance and a raspberry Pi 3 running a NextCloud container at home.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: