#[fluffy]With all of the recent push towards IndieAuth Ticket Auth, has anyone built a simple standalone PHP-or-whatever ticket endpoint for testing purposes that one could deploy locally?
#[fluffy]Also, are we just not providing scopes for ticketauth-provisioned tokens?
#GWG[fluffy]: I was going to ask that. The scopes question
#[fluffy]looks like there’s also an open debate about the whole ‘resource’ thing, like whether a token should be valid for the whole site or just for the page it was requested against. IMO it should be up to the ticket granter to make that decision, since like… in my case when someone’s logging into my site, I’m giving them a ticket for the whole site.
#GWGWell, if we base it on resource indicators, it should be valid for everything under the URL.
#[fluffy]yeah I plan on making my thing flexible, and also in my implementation the ticket itself is going to be a short-lived token with a scope of ‘ticket’ in addition to whatever other scope(s) are on the request
#[fluffy]and then the final token grant will have the ‘ticket’ scope removed
#GWGI'm just excited that we're making some small progress.
#aaronpkScope is usually for limiting what a particular access token can do within what a user is allowed to do, it's not meant to represent limited access by other users
#aaronpkIMO this is the line that a few of the OpenID connect specs cross over inappropriately
moose3338, alex11 and [jacky] joined the channel
#ZegnatI agree with aaronpk, and was planning to use scope just as indieauth has it. For my current tickets I never set scopes because I am not really authorising the user for anything. All the tokens are basically authentication only tokens. I just want to know who is visiting, my website can use that to figure out what you get to do.
#jamietannaI'm sure aaronpk wrote a gist for a self-contained endpoint, fluffy, but I can't seem to find it offhand
[fluffy] joined the channel
#[fluffy]regarding scopes, yeah, I don’t personally have any particular reason for caring about them beyond just wanting to interoperate correctly.
#[fluffy]also it was a convenient place to shove in the “this token is being used as a ticket” without having to like. change my serialization again.
#[fluffy]and Publ definitely handles user-level permissions internally rather than trusting the scope of the token.
#[fluffy]and of course the initial use case for TicketAuth implies a read scope anyway. I don’t really see any use case for using it with, say, micropub
#[fluffy]for that matter, when you sign into Publ, it only requests a ‘profile’ scope as a matter of having *something* in the scope (since the spec requires it) and even if something were to actually provide the profile with the authorization response, Publ doens’t use it; it just parses the h-card from the ‘me’ URL.
#[fluffy]incidentally I made a decent amount of progress on adding the ticket grant flow to Publ but then I got distracted by a music project with a tight deadline. Hopefully I’ll have TicketAuth working within a few days.
GoldenEye joined the channel
#jamietannaSo I've got a ticket receiver up - I've gone for requiring the `issuer` parameter to tell me who's issued the token, so I can then look up their profile information. I've put it as a Ruby POC on Heroku so will share the code + add details to the Wiki shortly
#jamietannaBeen able to get a token from Zegnat - although as mentioned, I needed to manually add the `issuer` so it didn't work out-of-the-box
#jamietannaZegnat I do see `"me": "https:\/\/www.staging.jvt.me\/",` - is that the expected format for your `me`s?
#ZegnatSo aslong as you are JSON decoding, they should disappear on your end again.
#jamietannahttps://stackoverflow.com/a/10210433/2257038 has a good answer to it - it looks like you can resolve your end as it's not needed to be encoding the slashes (as i.e. Ruby out of the box isn't removing those slashes when I JSON decode)
#ZegnatI could probably add that flag. But do note that even the latest JSON RFC still allows escaping forward slashes. So even if I do so, it is not at all guaranteed that every implementation you run into does so.
#ZegnatHmm, not even I-JSON changed anything about that, so for interop they assume that all JSON parsers support escaped forward slashes
jamietanna1 joined the channel
#jamietanna1Of the languages I've worked with, I think PHP is the only one that does that by default tho 🤔
[fluffy] joined the channel
#[fluffy]forward-slash escaping is necessary to support in JSON because of the need to stop </script> from being interpreted by the HTML parser if the JSON blob is inside a <script> section.
#[fluffy]It’s silly that PHP’s JSON encoder escapes *every* forward slash, though
#[fluffy]presumably it was substantially easier to write that way
#[fluffy]BTW where in TicketAuth is this ‘issuer’ thing documented/being decided?
#GWGSo, proposal is that the ticket optionally have a me property indicating the identity of the sender of the ticket, where the token endpoint can be discovered
#GWGIf the property isn't sent, the ticket endpoint should discover the token endpoint at the URL of the resource
#ZegnatIs me really the best name there? Because that will be a different me then will show in the token after exchange. Wonder if we end up overloading what me means
#GWGProperty name aside, does the behavior make sense?
#GWGThat it is optional and that if not present, discovery is run on the resource instead?
#aaronpkThere is a PHP flag to stop it from escaping the slashes. I try to use it whenever I can
#@AndreJaenisch↩️ Which of those is not a CMS?
I want to receive WebMentions by exposing an API endpoint on my domain (with MariaDB and everything), so basically look for a library.
I'm okay with http://WebMention.io, but I can do more if all data are under my control. (twitter.com/_/status/1412783624869584900)
#@schnarfed↩️ Ah, you didn't mention you wanted a standalone library. There are lots of non-CMS webmention receivers there, in the service sections, but you're right, not many libraries, probably because receivers generally need to store mentions somewhere, which is implementation-specific. (twitter.com/_/status/1412785473760546819)
#@AndreJaenisch↩️ Yepp.
For now, I'll point to http://webmention.io as I move my code towards my own domain.
Then, I'll look into fetching all data there and put it into my own database before I write an endpoint.
I mean, libraries like PonyORM or Knex can handle multiple database backends. (twitter.com/_/status/1412787332130951175)
#jamietannafluffy there's a bit more thinking under the question "Where does the ticket endpoint go looking for the token endpoint?"
#jamietannaI agree that not using `me` makes sense, and that `issuer` makes more OAuth2-y sense
#jamietannaGWG I think that approach sounds reasonable _but_ instead of complicating things for receivers, why not just require i.e. `issuer` to always be sent?
[tw2113_Slack_], rockorager and [snarfed] joined the channel
#[snarfed]rockorager I assume that >6M POST was a video?
#rockoragerNo, just a random photo from my phone. I was testing from both quill and Sunlit
#rockoragerAfter you account for base64 encoding, max image size is ~4mb
#rockoragerIt's just annoying because Netlify gives you nothing when AWS rejects for size limit...you just get no request at all, so you can't even send back a nice error code from inside Netlify
#rockoragerQuill ends up showing an immediate error, and Sunlit keeps going and then times out with an 'internal server error' after about 10 seconds
#[fluffy]Okay I finally got around to reading the discussion of issuer vs. resource on the wiki. I think people might be working cross-purposes on those things… it seems like some folks are using TicketAuth as a means of providing notification about a specific resource becoming available, and some folks are using it as a means of granting the ability to follow a feed or the like.
#[fluffy]My expectation of TicketAuth was for the latter case - that I’d be giving people a bearer token that they can use when pulling my feed from my site, rather than giving people a bearer token to access a specific page.
#[fluffy]Like I guess what I want my token generation to be for is more of `realm` than `resource`.