Public endpoints returning error 300

[scottthesecond]

Bug Report

When an endpoint is set to be publicly readable, the API still returns error 300 when trying to read it. See screenshots below for demonstration.

Steps to Reproduce

1. Create a collection and add items
2. Set the collection to be public in the
3. Attempt to access to public endpoint

Expected Behavior

Items in the collection should be returned

Actual Behavior

Error 300

Other Context & Screenshots

All collections are set to be publicly readable

When attempting to access the items via the API, access is denied.

Technical Details

• Device: Virtual Linux Server
• OS: Ubuntu 16.04.2
• Web Server: NGINX 1.10.3
• PHP Version: 7.2.16
• Database: mysqld Ver 5.7.25-0ubuntu0.16.04.2 for Linux on x86_64
• Install Method: cloned master branch of https://github.com/directus/directus.git

[rijkvanzanten]

This seems to be working as expected for me on the live demo version. If possible, could you share a dump of the database so we can reproduce your exact setup?

[scottthesecond]

For sure.
DB Dump is here: https://unnamedmedia-my.sharepoint.com/:u:/g/personal/scott_unnamedco_com/Eedg3zyxkGlIkxPhlUfGo_4BW0CzsEEHjilfoD9Orh0nWQ?e=I82bZx

[scottthesecond]

Hey @rijkvanzanten-- I believe I've discovered what the issue is, and it might be a somewhat special or unique case.

The problem seems to be that the tables were initially created with the default "status" fields Directus adds, and so when the permissions were set, the directus_permissions table had a value for the different status options:

After experimenting with the tables for a while, we removed the status column from the table without thinking about it. Apparently, even when I set the public read permission after removing the status field from the table, it still didn't want to let me view the items publicly:

I thought it was odd that the permissions with the statuses were still there, even though that column didn't exist anymore, so I manually removed all entries in the permissions table and added a new one with the "status" set to null

And I am now able to access to data publicly:

So this one may have been a special problem caused by unique circumstances and/or my own stupidity. Do with this what you will, but maybe it would be beneficial to have the app remove status-based permissions when a status column is removed? I imagine that's not a super high priority issue for you to address, however.

[rijkvanzanten]

Thanks for clearing that up @pessimisticpaperclip!

[binal-7span]

@pessimisticpaperclip

The system is working as expected so this can't be actually considered as a bug. Take a scenario:

You've created 2 statuses:

1. Private
2. Public

You have records & its permissions are based on status.
Now if you remove the 'status' fields & we make those available irrespective of 'status' permission, it will expose unwanted data.
To make a data public again, you should again explicitly define the permissions, either globally or based on status.

To make this flow stable, I've made changes in conditions like when you delete the status field, it removes all the status related permissions and hence the items will be private.

You can check that from #896