hotmeteor / receiver Goto Github PK

Is your feature request related to a problem? Please describe.
For the Postmark provider it (annoyingly) authenticates the webhook using one of my app's users via HTTP basic auth. It's kinda silly to have to setup a special user in my app just to authenticate the webhooks. Then I would want to add logic to my login page's controller to exclude the possibility of logging in as that user on the main website for if those credentials where somehow leaked.

Describe the solution you'd like
In my opinion it makes much more sense to authenticate the webhook by IP address instead of the current method. And maybe add a config value to add additional IP's such as localhost or other special purpose IP's for testing.

Describe alternatives you've considered
I have extended receiver with my own Postmark provider to accomplish this for now.

Additional context

Thanks for this great package. I notice that right now, for any given driver if a webhook is sent with an event/topic that doesn't map to a handler class in that driver's namespace, the code just quietly finishes and returns success.

I wonder if it would be helpful to allow the definition of a fallback class that would be used when no event-specific class is available?

I could imagine implementing this by hardcoding a class name that would be used (e.g. "NoEventHandler.php") or by allowing users of the package to define a fallback class in the receiver definition, e.g. through getFallbackClass(): string or similar.

Short version: is there a recommended method or function for determining if a $driver string specified in a request is valid?

Longer version: I have a service sending webhooks that wants to get a 200 OK back from a GET request to the webhook endpoint before it will activate the webhook. It doesn't use the "challenge" approach so I don't think the handshake method is going to work here. I'm adding a simple method in the controller that will be reached by a GET route, but I'd like to return 404 when the driver specified isn't valid, as a basic check against typos or an invalid driver being otherwise specified.

It looks like right now this package just relies on the illuminate/support package to throw an exception when the driver doesn't exist, but maybe there's a way to check that more intentionally? Something like Receiver::driverExists($driver);?

Thanks for any suggestions you can offer.

I have been evaluating if this package would work with Xero webhooks.

One thing I would like to know is if there is a way in a custom provider to handle multiple events in the one request. This is how Xero handles webhooks by sending an array of events that you then loop through.

Example payload:

{
   "events": [
      {
         "resourceUrl": "https://api.xero.com/api.xro/2.0/Contacts/717f2bfc-c6d4-41fd-b238-3f2f0c0cf777",
         "resourceId": "717f2bfc-c6d4-41fd-b238-3f2f0c0cf777",
         "eventDateUtc": "2017-06-21T01:15:39.902",
         "eventType": "Update",
         "eventCategory": "CONTACT",
         "tenantId": "c2cc9b6e-9458-4c7d-93cc-f02b81b0594f",
         "tenantType": "ORGANISATION"
      }
   ],
   "lastEventSequence": 1,
   "firstEventSequence": 1,
   "entropy": "S0m3r4Nd0mt3xt"

}

It is not clear from the Readme and other available documentation what configuration is required and where.

I'm working on handling GitHub hooks, and it has been frustrating to run into error after error while attempting to integrate the "drop-in" package.

For example, nowhere does it specify that my application's /config/services.php needs to be updated to include a webhook_secret configuration value, and that the same value needs to be configured in the GitHub webhook:

'github' => [
  'webhook_secret' => env('GITHUB_WEBHOOK_SECRET'),
],

I'd imagine there are similar requirements for other providers, too.

Improving the docs in this regard would go a long way towards easier package adoption.

In you README, it states:

Simply implement the verify method in your provider and return true or false if it passes.

Likewise, it states:

To facilitate this, implement the handshake method in your provider

However, both of the examples for these two methods show them being on the controller, rather than the provider.

If both of these methods are on the controller, it doesn't make it possible to group the verification and handshake with the provider itself. In any case, the documentation is confusing.

Can't receive if the tests are failing.

Receivers should be separated from the core package, much like how Socialite has https://socialiteproviders.com, a collection of Socialite providers maintained by many different contributors.

The current providers in Receiver can stay, but any future ones will be built as independent packages. Additionally, we should create a package that will scaffold out a provider for contribution.

I've installed the latest version running on Laravel 9 and PHP 8.1.

I'm getting this error message when trying to use the stripe driver:

InvalidArgumentException: Driver [stripe] not supported.

Not sure what I'm doing wrong or if this is a bug.

My implementation:

<?php

namespace App\Http\Controllers\Webhooks;

use Illuminate\Http\Request;
use Receiver\Facades\Receiver;
use App\Http\Controllers\Controller;

class WebhooksController extends Controller
{
    public function store(Request $request)
    {
        Receiver::driver('stripe')
            ->receive($request)
            ->ok();
    }
}

The change in v0.1.15 introduced in #18 created a fatal error for me when deployed to production. It may be my code, but here's what I saw:

The webhook event handling stopped happening synchronously, which was succeeding, and was moved to a queued job, which failed.

The code that ran to handle the webhook event is

<?php

namespace App\Http\Handlers\Woocommerce;

class UserCreated extends AbstractUserEvent
{
    public function handle()
    {
        $this->createContactFromUser();
    }
}

and the parent class has this construction:

<?php

namespace App\Http\Handlers\Woocommerce;

use App\Data\WoocommerceCustomer;
use App\Data\WordpressUser;
use App\Helpers\WoocommerceHelpers;
use App\Models\Contact;
use Illuminate\Support\Facades\Log;

abstract class AbstractUserEvent extends AbstractWoocommerceEvent
{
    private WoocommerceHelpers $wooHelper;

    public function __construct(public string $event, public array $data)
    {
        parent::__construct($event, $data);

        // Create a Woo customer object we can work with.
        $this->wooHelper = new WoocommerceHelpers();

        ...
    }

    protected function createContactFromUser(): Contact|null
    {
        $newContact = $this->wooHelper->createLocalFromWpUser($this->user);
        return $newContact;
    }

    ...
}

The error I started getting was:

local.ERROR: Typed property App\Http\Handlers\Woocommerce\AbstractCustomerEvent::$wooHelper must not be accessed before initialization {"exception":"[object] (Error(code: 0): Typed property App\\Http\\Handlers\\Woocommerce\\AbstractCustomerEvent::$wooHelper must not be accessed before initialization at <path>/app/Http/Handlers/Woocommerce/AbstractCustomerEvent.php:51)

So it appears that the __construct method in AbstractUserEvent is not run following this release. Downgrading to 0.1.14 fixed it.

Please let me know if there's any other information that would be helpful to understand or advise on what's happening. Thank you.

VS Code with PHP Intelephense is complaining about receive function (or any other function after the first one).

Code runs fine. Just IDE is complaining.