Protecting the data api with authentication

I must be missing something obvious. One of my projects is a public website where all of the content is public. I want to provide this content through the data API, but I want to control who can access it so someone can’t sumble upon (or share) the data api url allows any schmuck to grab all the content. Yes, I know that sounds weird…why have the data public if you don’t want people to have it?

Think of any music catalogue site that has an API. The data is ‘public’ but if you want to use it, you need to create a developer account, blah blah blah.

Enabling the data API makes it public and the data api url exposes all of the data in whatever thing I specify.

From my tests, there is no way to use privacy rules to make this content show up on webpages for non-authenticated users but force authentication on the data api url, unless I’m missing something.

If I disable everything in ‘everyone else’, as the docs say, no content shows up on the public site and the data api url is empty.

If I create a privacy rule using ‘current user is empty’, or ‘current user is not empty’, or ‘current user is/is not logged in’, the public pages and data api urls behave exactly the same.

I know bubble creates a user in session for all visits and expires that user after a couple of days. I cannot see any way to create a privacy rule that says “let anonymous user view these fields, find in search etc” but “force data api users to pass authentication in the headers”

Maybe I just need to build this myself? What the hell is the point of the data API if you can’t protect it?

1 Like

Yes it seems that currently you cannot differentiate between data fetched on-page and data fetched from the data API. I agree that it would be nice to have a way to do this.

The equivalent of this would be to set up a wf endpoint instead of a data endpoint, which i think would best suit what you are trying to do.

You could create a backend public API endpoont which cannot be run without authentication, and in it use the ‘return data from API’ action and just return structured json with a search. This workflow would also be more trackable than a data endpoint, and it would be possible to record usage and do more fancy stuff in the workflow. I would be surprised if music catalogue sites used the equivalent of data endpoints rather than workflow endpoints.

1 Like