LoqiIt looks like we don't have a page for "login@indieauth.com" yet. Would you like to create it? (Or just say "login@indieauth.com is ____", a sentence describing the term)
[tantek]hirusi[m], that's about as much as I can guess right now. We'll have to wait for aaronpk to help disambiguate what this means, though yes, we should have documentation to enable you to troubleshoot this directly yourself. thanks for your patience!
[tantek]on another topic I saw that https://macwright.com/2020/08/22/clean-starts-for-the-web.html was bookmarked to IndieNews, curious what people think about it or if anyone is considering a follow-up post with how the IndieWeb is already doing a lot of things for a better web?
aaronpkthen a couple minutes later they figured out how to automate it and started sending 30 requests per second. the server rejected some of those, some of them resulted in http 502 errors, but a lot got through
aaronpkI really should have built rate limiting of some sort into that, but I don't really want to add more code to that site, I'd rather spend the time building a replacement for it
LoqiIt looks like we don't have a page for "email authentication" yet. Would you like to create it? (Or just say "email authentication is ____", a sentence describing the term)
aaronpkif anything, a security considerations section could point to OWASP's authentication cheat sheet because there's *lots* more considerations than just this issue when dealing with authentication
[tantek]email authentication is an alternative sign-in method to the classic username password method, where the user only enters an email address, the site then emails the user a unique sign-in link, which upon clicking they are authenticated. If you add a [[rel-me]] link from your site to your email, then login services that support [[RelMeAuth]] may provide you the option of signing in via email authentication.
[manton]Much better to have [aaronpk] try to break Micro.blog now instead of hackers later. 🙂 This is definitely a problem… I think I’m going to start by allowing at most 1 sign-in email attempt every 30 seconds, just to have some protection in place.
hirusi[m]aaronpk: thanks for taking a look! have you decided if this would be tackled in the current build or just something you'd rather tackle in a fresh project?
aaronpkI'm trying to think of the smallest change I could do to prevent this, I think some basic rate limiting is doable. I just really don't want to sink a lot of time into it because I know I'm going to throw out all this code at some point. But also who knows when that will actually be.
[fluffy]For email signins what I do is I keep track of all pending email signins for an address and don’t allow anyone to request a new signin while there’s a pending, unexpired one.
[fluffy]Like, if someone requests a signin and the email doesn’t come to them, requesting another one during the timeout window probably won’t help matters.
[fluffy](This is the only thing in Authl that requires statefulness to work but the failure mode is that someone’s able to make some extra signin requests so it’s not that big a deal to me.)
[fluffy]I do also want to add rate-limiting based on originating IP address but that gets into framework-dependent territory so that’ll probably only be on the Flask frontend.
[manton]Whether you can block new emails while a sign-in is pending may depend on how long they are valid. For Micro.blog, the sign-in emails are valid for 24 hours, so blocking future sign-ins would not work. People often have email delivery problems that are resolved and then need to try again some number of minutes later.
[manton]Maybe 24 hours is too long, but I’d want it to be at least 1-2 hours since someone might request a sign-in, forget about it, then see the email later that day and expect it to work.
@skkboz↩️ "limited nuclear war" is the fantasy they will only go up in asia like the last time and only asians are affected.
china and/or north korea would send microsub/fishing boats/suicide planes into both San Francisco & LA and take out both cities and naval facilities w nukes. (twitter.com/_/status/1297922084559917056)
@skkboz↩️ "limited nuclear war" is the fantasy they will only go up in asia like the last time and only asians are affected.
china and/or north korea would send microsub/fishing boats/suicide planes into both San Francisco & LA and take out both cities and naval facilities w nukes. (twitter.com/_/status/1297921934747869184)
[manton]@GWG Good question about JSON Feed. I think 2 things: writing up a draft for the MIME type so that we can officially register it, and revisiting some of the early experiments for podcasting that some folks were working on (basically adapting the iTunes tags to JSON in a more vendor-neutral way): https://jsonfeed.org/podcasting
[manton]It’s always been a little annoying to me that Apple’s podcast directory requires extra fields, when really a basic RSS feed (or JSON Feed) has enough to support podcasting without the “itunes” namespace. But many clients and aggregators now expect at least a few extras, like cover art and Apple categories.
hirusi[m]I'm having second doubts about this but I certainly was thrown off with this behaviour so added an extra example: https://indieweb.org/Micropub#New_Article
hirusi[m]I had, for whatever reason, assumed that the mp-slug property would be reserved for just notes, likes etc. and not articles. So I've added that in... but... is this a) correct b) should this be kept in the wiki?
hirusi[m]Or we could revert this and add it to the Slug extension section on the Micropub-extensions page itself. An extra line to clarify it is acceptable for all post types
swentel[snarfed], thanks for the followers list. Additional questoin re: .well-known/host-meta - do you know whether that route is mandatory? of is .well-known/webfinger good enough. Been looking around a bit for docs about that, but can't really find anything conclusive.
GWGswentel: It was prompted by Indigenous behavior. I implemented it because I use Indigenous. So, I tried to put it in extension terms as a way to do form encoded h-geo and h-card
[tantek][snarfed] correct, AP does not require any "well-known", none of the Social Web WG specs do. We adopted "follow your nose" discoverability as a design principle quite up front, which rejects any "magic place" knowledge type design like "well-known".
sknebelhm, looking at that podcast link above, chapters are another thing. although they are already in the media file, so they don't really need duplicate markup maybe. (links with mediafragments might do the job too)