WebHook log

Where can we see the log of all WebHook.

I want to be able to diagnose our problem but can't find any log of the web hook we use.

What I want to know is the date and time of every request made by a web hook and the result it got from our server.


I would guess that there is no such thing, because every EVERY time I wrote something here, the answer is always. "You can't do this."

If this is the case, not allowing developers to diagnose their own web hook is a real pain, and I would not be surprised of that because, as usual, things seems to be half developed on your end.

Take this a constructive comment.... or not.

 

I hope you will prove me wrong.

7 comments

  • raphaelraphael Member Posts: 39

    You are definitely right.

  • flexjolyflexjoly Member Posts: 37

    Well of course you (as developer) log the received webhooks, but I also miss the log part in the admin of ecom.

    From the viewpoint of the shop-owner it is really needed that he/she can see which webhooks are linked to ecom and what they do. So far I did not find any info on webhooks or even on the api-connection in ecom-backend.

    This sounds very risky to me, since it is impossible for the shop-owner to see what his api-developer is doing...... My boss calls this a possible 'man-in-the-middle-attack' .....

  • gregaricangregarican Member Posts: 708 

    The way that the API credentials are granted access to a Retail shop helps prevent the MitM scenario. The Retail user needs to authenticate against the shop with their own credentials in order to view and authorize the API consumer's access to their shop. Along with that there is an explicit statement of the access scope. And if the Retail user would later on be concerned about any going-on, they can just revoke the API credentials so the consumer cannot access their shop.

    Although visibility into eCom webhooks would make sense from the shop user's perspective. Via the web front-end. Makes sense to me!

  • raphaelraphael Member Posts: 39

    "Helps prevent," is never a good solution when talking about security.

    Here is another reason why it's important to have access to this data from the sender perspective:

    What if the internet link goes down between light speed and the webhook receiver? No log at all..

  • gregaricangregarican Member Posts: 708 

    "Helps prevent," is never a good solution when talking about security.

    @raphael I'm not sure there exists a solution that 100% prevents anything/everything 100% of the time. If it does then I'd love to get in on their IPO stock offering 😀

    In the scenario I outlined, in order for a Lightspeed user's store to be compromised by a bad actor:

    1) The bad actor would have to learn of and use the Lightspeed user's credentials.

    2) The bad actor would then go through the API OAuth process in order to grant the API consumer access to the store.

    3) These steps being successful is predicated on the assumption that Lightspeed's Cloudflare provider wouldn't block the abnormal client IP coming in.

    4) If a bad actor had access to the Lightspeed user's credentials then why take the time to engineer a series of API exploits? With full access to the web GUI as the Lightspeed user, they'd have all the access they need.

    This is all assuming the eCom's authorization routine is similar to that of Retail.

    All of that being said, I do agree about some sort of webhook logging being available to the Lightspeed shop user. Being able to troubleshoot and validate what all is going on is important. I know in Retail I can go into individual records and see in the logs that the API consumer created or modified things. Having similar visibility to eCom webhooks is something that should already be available really.

Sign In or Register to comment.