7440dc2145
Make the logic match the intent described in the comments. The intent is clearly "accept notices whenever (A or B or C)", but the logic implemented was more like "not ((not A) or (not B) or (not C))", which is a basical boolean algebra fail (each of those ORs need to become ANDs for double-negation to work). The practical implication was that, for example, writing a reply to someone else's notice and including an @-reference to _another_ user on another site to bring them into the discussion would fail to deliver the notice to the new user because their server would basically say `oh no, you can't message this user from someone else's thread' because an earlier check for the `A' or `C' parts of `(A or B or C)' prevents `B' from being checked. cf.: <http://status.hackerposse.com/notice/55846>, which was refused by the nhcrossing.com server because it didn't know about <http://sn.jonkman.ca/notice/93724>, even though it would have passed the later `notice contains a reference to a local user' check if not for an exception being prematurely thrown. The whole idea of reporting `which specific check FAILED' in an `if ANY SUCCEEDS' analysis is just bogus, so nix all of the distinct ClientExceptions--a single `ALL FAILED' exception is the only one that makes sense. |
||
|---|---|---|
| .. | ||
| groupsalmon.php | ||
| ostatusgroup.php | ||
| ostatusinit.php | ||
| ostatuspeopletag.php | ||
| ostatussub.php | ||
| ostatustag.php | ||
| peopletagsalmon.php | ||
| pushcallback.php | ||
| pushhub.php | ||
| salmon.php | ||
| usersalmon.php | ||