As an API producer, I want to be certain that the incoming request is from Blobr so that I can connect the Blobr group/product/subscription IDs to customer accounts on my own end.
From my end it looks like the API request proxied through Blobr gets a few additional headers added to it:
POST /path/to/my/api HTTP/1.1
blobr-group-id: grp_6f3f8746b31652d6
blobr-product-id: prd_d71603d15caf7a78
blobr-subscription-id: sub_22266fad7ed1e990
On their own, there’s no way to verify that this request came from Blobr, ideally without checking against a (cached) list of “Blobr IP addresses”.
Please correct me if I’m wrong - I’ve been looking for a public Blobr API where I can make an authenticated request to check the group/product/subscription ID is valid, but as of today I find anything.
One way this could be solved would be to attach a signature header, which is signed using a secret key per-API which the API producer (e.g. me) would get from the Blobr Dashboard when adding my API to Blobr & then configure on my end. For example:
POST /path/to/my/api HTTP/1.1
blobr-event: GET /my/api 2023-04-01T01:02:03.000Z
blobr-signature: sha256=860514dcea4e1d3566e3c058863465b878309bf236d01
blobr-group-id: grp_6f3f8746b31652d6
blobr-product-id: prd_d71603d15caf7a78
blobr-subscription-id: sub_22266fad7ed1e990
In this example the API request has a signature which is calculated by hashing the blobr-event & secret-key together (in a similar fashion to webhook signatures from services like GitHub. Obviously in Github’s example, they’re signing the event/request-body whereas for Blobr that’s not always applicable, hence my example is signing another header which has also been set by Blobr.
Obviously there are wider security questions around my example implementation, such as replay attacks, but hopefully it’s enough to explain my thought process around this.
Thanks for your question. I am very sorry I missed it. Don’t forget that you can also share your questions directly from the app, on our chat.
You’re right, the API request proxied by Blobr gets additional headers so you know it’s coming from Blobr. These headers also help you understand who is consuming what.
Thanks for what you shared, I understand your case. In fact, providing a list of Blobr IP is part of the Enterprise plan, and the Blobr API is on the roadmap.
We could discuss it to better understand your needs and requirements. We can then advise you on the best way to proceed. You can book a meeting slot with us anytime via this link: https://meetings.hubspot.com/georges-lagardere
Thank you and feel free to reply to this thread if you prefer to stay in writing!
Do you have any documentation for the additional headers Blobr attaches to requests? I’m struggling to find anything concrete around how we’re expected to use these values - thinking just-in-time provisioning for customers using these headers, do you think that is a sensible idea?
The core of the problem is: right now, there’s no way for us to “know”/identify customer information for our own records when a request comes through Blobr… without a human signing into the API dashboard & looking them up by hand! Any ideas on the best way to identify customers automatically? Are there webhooks we can subscribe to when customers come & go?
Please don’t hesitate to contact me on the chat directly, I will reply as soon as I can.
Thanks for your reply on the topic. I understand your comments. That’s why we are working on the subject in order to: provide more headers for you to identify customers more easily, but also provide the Blobr API from which you could retrieve additional customer information.
We are finally improving the analytics section so that you get different analytics reports with all the info you need from your customers, who they are, what they’ve doing and so on. That would be helpful to better understand what you would need to do with your detailed customer data, include this your CRM for instance?