[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]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.
[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
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
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.
[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.
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
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.
[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.
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
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
@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)
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?
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
[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.