Running a backend workflow that logs the user in will return an access token, valid by default for a year
Setup a backend workflow that can only be run by an authenticated user - appending the generated access token as an Authorization header and calling from your plugin will invoke the endpoint. Make sure the workflow cannot be invoked without authorization. Return a generic success/error message as per requirements.
Then no need to store the access token your side - as long as the user exists on your Bubble app, them being able to invoke the workflow proves auth. You could perhaps add a search for current user to return some user meta data, again using this as further validation?
You will need to think about token refresh though each year
I only need to report the site using my plugin. After that is all backend validation. No tokens, just a user specifying their site name and it’s good to go.
With the token method, it’s doable the way you mentioned as well, just a little more work involved. Either way the end-user is still going to need to get that token from you somewhere, right? So having them enter a token isn’t really necessary.
Also note that if you don’t obfuscate your code well, the key portion can be bypassed (also depends on how much functionality is on the plugin itself). So it’s best to include the main-line features with your third-party and allow the site accessing the plugin.
You can easily return the app name and site URL back to your DB, and process your workflows accordingly.
I would probably use a traffic router to do this. Probably a Cloudflare worker. Maybe you could store the key that you provide in a Cloudflare object and then any real API calls that you’re plug in might need to make should actually just get routed to and be executed via the Cloudflare worker which could check to see if the key that the client is passing is valid by validating it through the cloudflare object and passing back the relevant data package
Are you worried about somebody ripping off your code in the client side portion of your plug-in?
Some additional context would indeed be useful. My plugin does the following:
Takes some info that the user inputs and passes it to an AWS Lambda function
The AWS Lambda function does some stuff with that info
And then returns a file to the user of the plugin
This is going to be a subscription product. Once the user subscribes to the product on my website (which will be built with Bubble), they’re going to be provided with an access token. They’ll then input that access token to the plugin.
The point of the access token is to only allow those users who have subscribed to use the plugin.
This sounds promising @jared.gibb, but I’d like to avoid having to use Cloudflare if at all possible
No not at all. The bulk of the heavy lifting is done in the AWS Lambda function, so no biggie if someone can see my client-side code (although I will of course obfuscate it).
If anyone has any additional insights based on the info above, it would be fantastic to hear
