Thanks for the info. I’ve written the widget in React, and then I run a webpack build to bundle it up. I add a script tag to link to that bundle. Do you see any issues with this setup?
Currently i’m using socket.io to communicate between the widget and my meteor app. It seems to work as expected, but am not sure if this is an ideal solution.
What i’ve currently done to identify requests, is check the hostname of where the widget is installed (eg. localhost) and pass that up with emitted messages. I have a field on the Meteor.user() document which contains their website. The obvious issue is that a user could sign up and enter a URL they dont own (like example.com) and they would be able to see messages that were emitted from that site if the widget is installed there. What is a better way to handle this scenario?
No issues, but React does increase widget file size. My personal opinion is that a widget should be as small as possible so that it loads as fast as possible.
The way Intercom does it, is to identify the app user (by email) and pass that on to the widget authentication. So then you do widget authentication based on domain and email.
Another way is to have the user prove ownership of the domain, like setting a CNAME DNS value and read that during setup of the widget. That’s how Google is doing it.
@satya, i have very similar requirements for a project. Your experience and resource will greatly help. Is it possible to share a github link to your implementation please?
It would be awesome if you could write a tutorial on it in (i.e. how you implemented it in your application), but obviously truncate some parts.
Anyways, thanks for this post. I’ll look over it and try to make sense of everything.
A quick question, though:
Authentication via a widget that can be embedded on someone’s website: Do you set up the classic Node routes/API, where the widget ID or some other ID is embedded in the URL and you can then validate it, input data in the DB that way, etc?