heads up: I merged portier/portier-broker#174, which changed
token['email_verified'] to be a boolean instead of the email address
No, I think it's confusing and bad as well. Back then we had it all solved with Miranda/Pidgin and now chatting is a mess again
but we should use this channel here to coordinate the blockers. You were wondering on how to announce the change to the public broker?
Yes, it's mostly about the change in normalisation. I had this comment where I tried to outline scenarios: https://github.com/portier/portier-broker/issues/165#issuecomment-475556791
I updated it, because new releases fix a bunch of stuff at least for Node.js and PHP, but it still requires people to upgrade.
Well, and to update the spec. Though a c lear "you need to do this now" page would be helpful. Frankly, I got confused by the scenarios
I assume that should be fair to everyone using the public broker. Pipes should be one of the "biggest" users anyway
Given how the activity in the project is you need no further mandate to change this
But you are listed as owner too?
Hyper 0.13 is out, I made a hyper-staticfile release, and this PR is now ready to go: portier/portier-broker#189 🥳
Oh, wow, apparently it fails on stable and nightly, but not beta. And I happen to be on beta.
@onli If
I haven't heard about Gmail issues, but I don't think we have a lot of users on the gmail.com domain. Most of our users are probably G Suite or an Exchange server.
We are (very slowly) debugging a G Suite issue, though, but I suspect this user is not using his actual account name but an email alias to login.
id_token is missing, there should be error and error_description instead. (Those are the two return_to_relier calls in the broker.)I haven't heard about Gmail issues, but I don't think we have a lot of users on the gmail.com domain. Most of our users are probably G Suite or an Exchange server.
We are (very slowly) debugging a G Suite issue, though, but I suspect this user is not using his actual account name but an email alias to login.
Would be awesome if we could also package and upload on all platforms. :)
We need a place to upload. I think ideally we'd just attach something to github releases, but I haven't figured out how to automate that yet: https://github.com/portier/portier-broker/releases
And we'd need to figure out package formats. Besides the binary, we currently ship
lang, tmpl and res directories along, which are all I think /usr/share-like data. The way we load these currently relies on the working directory where you run the broker, which is probably something that should change. But maybe we can avoid OS-specific packaging and just ship a zip/tgz for now.
but we should definitely keep the option of just having a binary and local files
Hmm, I should probably have a toplevel directory in the archives, though
Man, I'm again annoyed by JWK and OIDC standards. I was hoping to add Ed25519 support, and I'm well on my way to doing that in very much non-standard ways. Apparently, OIDC has no way to select a signing algorithm, and relies on whatever client registration you build on top of it (which we skip entirely). But there is an
id_token_signing_alg_values_supported field in the discovery document, implying there's an id_token_signing_alg parameter somewhere, but that doesn't exist? On top of that, the JWA alg value you put in for Ed25519 is EdDSA, which is a broader category and means you could get something else, like an Ed448 signature. 🤨
That's the original spec I think? I didn't even notice, but for ECDH they have very specific values in
alg. But this is the document I found for EdDSA: https://tools.ietf.org/html/rfc8037
And that has a separate
crv field, instead of just encoding it in alg, which is weird
Darn, that's a
ring dependency