D10063 is likely a fix, but I need to test the POST part and that'll take more than 5 minutes to set up.

Support Impact This feature is fairly useless right now for all but the simplest things.

One concern about this is that this information is policy-bypassing.

Given that there are basically reasonable approaches for doing Conduit from an arbitrary HTTP-capable client now (T5955), adding more PHIDs/URIs is safe but we should probably remove all the text/markup from these requests. The expectation is that the endpoint receiving the POST will make a Conduit call to feed.query (or similar) in order to retrieve a rendering for the story, under some set of credentials which we can do policy checks for.

This would align this better with existing un-authenticated notification channels, like Aphlict, where you can know that something happened (and get some information about what object(s) it affected) but must be authenticated to learn any substantive details.

Although I don't think this is particularly important, landing some version of D10063 is probably worthwhile since people who try to use it often end up pretty blocked in reasonable use cases. It's only blocked by it being kind of a pain to set up and test.

@epriestley: this task being fixed might be an easier solution than writing our own Doorkeeper integration (as discussed on Conpherence today). I already have an application that receives feed data via POST; can I help test this change so we can get it merged?

In T5726#88706, @epriestley wrote:

One concern about this is that this information is policy-bypassing.

I've digged into code a bit and found this in src/applications/feed/worker/FeedPushWorker.php:

$story = id(new PhabricatorFeedQuery())
      ->setViewer(PhabricatorUser::getOmnipotentUser())
      ...

I'm completely unfamiliar with Phabricator codebase, but it seems honouring policies is as simple as adding feed.user config option and using it instead of OmnipotentUser there.