Aaron Parecki

@aaronpk I'm going to have to watch for these in the future. I didn't see this one until three minutes ago!

@aaronpk Going into my settings it looks like it's already set to use Local Endpoints. Maybe that's the issue?

Not sure what could've change to cause this issue.

@aaronpk I've been experimenting with that for the Micro.blog for Mac app. We'll see how it goes. Seems like a better fit than web upload because of the file sizes.

For anyone who downloaded their Instagram archive, how big was the .zip file? Mine was 30 MB, but I stopped posting last year and only had a few videos. Wondering if the average size is too big for anything except as a backup.

Hi @aaronpk

When I add the first line, this is the error message I get (when attempting to send a previous post to my site - after the verification process):

HTTP/1.1 100 Continue

HTTP/1.1 500 Internal Server Error Server: nginx/1.12.2 Date: Sat, 28 Apr 2018 06:32:25 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Endurance-Cache-Level: 2

That is the same error message I get if I remove that line and add the second line you suggested (I'm assuming you didn't want both lines in the .htaccess file).

A potential manual way: have a !snooze command that blacklists a string for e.g. 24 hours.

@aaronpk Enjoy it :)

@aaronpk This is a privilege that I enjoy far more than many programmers... thanks for the reminder.

This totally slipped me by, so here we go. I do like the idea of logging things, and syslog() is probably the best solution unless we want to pull in something like PSR-3. More thoughts:

1. I would not turn any logging on by default. I do think logging IPs with authentication requests makes sense, and I would simply never want to log any IPs by default. Especially when people running this on shared hosts might be feeding it into logs they themselves cannot clear.
2. LOG_FAILED_PASSWORDS sounds like a nice-to-have that needs massive disclaimers around it. We can’t work on the assumption that everyone is using a password manager. This means people are typing their passwords, and typos happen. This option sounds good, but if you over time fill logs with deviations of your real password, you better be making sure you are purging those logs real good. (Of course again with the problem that syslog() may be out of reach to the user who unwittingly turned this on.)

I can almost see us strategically dropping these into the source code, but commented. Anyone who understands syslog() and wants to use it to trip up other alarm bells on a server, will probably be OK uncommenting a couple of functions. Even if they aren’t well versed with PHP. This will at least keep it out of the hands of users who cannot see the possible side-effects.

Like the idea, just not sure how to execute it without giving users some flags in the config with huge warning disclaimers. And I don’t like warning disclaimers in what is supposed to be a simple single-purpose thing.

I love programming.

I definitely agree! It was a huge improvement when they switched to subscription!