I enjoy your bootable OS things conceptually, and I hope you make more of them.
mondecitronne
we are yet to be introduced to various mechanisms which will alter our ability to so brazenly ascend forth, particularly that of skin.
who is mark?
— citrons
- joined
- a very long time ago
recent posts
I'll look at all of the new GEORGE applications tomorrow and also answer all the john emails.
no, it would be zeusofthecrows@gmail.com
. you can add +thing
to your email address, and it delivers to the same address but obviously with a different "from" address.
crushing the words down so that they fit into the display sounds unpleasant. you could just deal with the large text size and scroll quickly.
NBT is not JSON at all. it's not supposed to be. it's actually a binary format with a textual representation. "Named Binary Tag". JSON is used in the game in other places (like in formatted text), and it is used compliantly.
well, yes, because non-fresh orange juice isn't stale, due to the impossibility of staling.
well, I speak only for myself in saying this, but perhaps the speed at which applications are processed is reflective of a nonfunctional sense of time.
i thought ./well-known was an april fool's joke
why in the world would you think that?
why would someone have both /.well-known/citrons/auth and /citrons/auth?
I'm not saying they would. just read RFC 8615. it explains /.well-known.
why /.well-known/citrons/auth? why not just /citrons/auth?
what if you wish to have a page at /citrons/auth? /.well-known is a standard path for these things.
this is seriously cool!!
thanks!
I have many potential/work-in-progress projects which require account systems. I figured heav, apparently, figured that optimally, I should implement this once and then never again. this is ultimately better for the user, also, as they must keep track of fewer accounts.
as such, auth.citrons.xyz exists. it is usable by anyone; though, I disclaim responsibility if it explodes.
the API documentation is todo, but the gist of it is this:
a service is identified with a domain. to discover a service, e.g. example.com, the authentication service queries https://example.com/.well-known/citrons/auth
. this is required to be a JSON file containing the following properties:
name
- the name of the serviceendpoint
- a URL in your application a user id and token can be POSTed to.
when you wish to log in a user, link them to https://auth.citrons.xyz/login?service=<domain>
. the user confirms by submitting a form to your endpoint
. the form contains the user's ID in uid
and token in token
.
you can then query the status of a token by posting it to https://auth.citrons.xyz/api/user/<user_id>/auth/<service_domain>
.
$ curl --request POST \
--data 'token=XXXX' \
https://auth.citrons.xyz/api/user/50fc23f03043d139/auth/example.com
{"valid":true,"user":{"username":"citrons","ttl":800,"uid":"50fc23f03043d139"},"ttl":800}
$ curl --request POST \
--data 'token=invalid'\
https://auth.citrons.xyz/api/user/50fc23f03043d139/auth/example.com
{"valid":false,"ttl":9999999}
ultimately, it is now possible to log in. by the way, I have designed the site around the new style I am working on for my site redesign, my new webæsthetic.
enjoy. tell me if you find some horrible bug.