firewalls: default: # default limits to 5 login attempts per minute, # the number can be configured via "max_attempts" login_throttling: ~ # define your own RateLimiter login_throttling: limiter: login Great high-level features Throttling Login Attempts
fi ler Speci fi c PHPUnit constraints ... An Ecocsystem with a Shared Experience It's also about the processes: BC promise Release cycle Security management Consistency across the board ...
✓ DKIM ✓ Draft Emails ✓ mailer:test command ✓ Tags and Metadata Currently supported by MailChimp, Mailgun, Mailpace*, Postmark, Sendgrid, Sendinblue, Amazon SES* The power of the community Based on real-world needs
components like HTTP Client, Noti fi er And some custom code for Stripe Webhooks Slack support here was key to creating the Notifier component Second use case for Webhooks...
Are there any best practices that could be abstracted and enforced? Is it generic enough to build a useful and reusable abstraction? Could Symfony leverage it in some components? Would it be useful for many of our users?
✓ Support Mailer and Noti fi er ✓ Consume and send ✓ Replay payloads in tests ✓ Prevent production replay ✓ Promote dataless noti fi cations ✓ Check payload signatures ✓ ... Abstract and reuse Implement common "best practices" Fully featured
one system to another system of some state change A successful payment in Stripe Twilio sent an SMS successfully A SaaS provider or an internal system Your application It allows to react to changes from external systems What are Webhooks?
new IsJsonRequestMatcher(), ]); } 1 Incoming HTTP Request Validation return new ChainRequestMatcher([ new MethodRequestMatcher('POST'), // https://postmarkapp.com/support/article/800-ips-for-firewalls#webhooks // localhost is added for testing new IpsRequestMatcher(['3.134.147.250', '50.31.156.6', '50.31.156.77', '18.217.206.57', '127.0.0.1']), new IsJsonRequestMatcher(), ]); Enforce provider security Reuses HttpFoundation infrastructure Used by Security
providers ‣ Validate event names and common payload items ‣ Write tests ‣ Write documentation Next Steps? I will submit the Pull Request after the 6.2 release
[ 'id' => 1, 'name' => 'Fabien Potencier', 'email' => '[email protected]', ]); $this->bus->dispatch(new SendWebhookMessage($subscriber, $event)); Sends the Webhook via HTTP async What about providing Webhooks to other applications? Application defined Payload
$event): void { error_log('Receive an internal and generic event '.var_export($event, true)); } } Some other Symfony application(s) Consumers can be anything ... including Symfony itself for SOA/micro-services/multi-apps/...
string $id, private array $payload, ){ } public function getName(): string { return $this->name; } public function getId(): string { return $this->id; } public function getPayload(): array { return $this->payload; } } Alternative transports: Queues for internal systems APIs ... A Webhook is just one possible transport for an event - via HTTP
structure ‣ Payload converters ‣ Consumer code push Webhook: A system makes real-time HTTP requests to other servers, the payload is an event API: A system API endpoint that can be polled on-demand; It returns all events that have occurred since last request pull Only useful if the provider supports Webhooks and an API for events
API: which one to use? Many providers provide both Good providers mitigate those Webhooks Uncertain security Downtime might lose events No ordering guarantees Needs some tunnel to test locally Frequent HTTP rq without new events Depends on provider retry strategy Expose a web server Security depends on the provider Don't call us We will call you Matters sometimes
‣ Logs / Audit trail ‣ Production Replay prevention ‣ Dataless noti fi cations ‣ Support for CRM, payment gateways, ...? ‣ ... Next Steps? The main concepts and low-level infrastructure are well-defined or wait a few years :)