Anonymous Access Control - Now the User can allow anonymous accounts to access your backend with customized access. For more details, please refer to this link.
– Anonymous access controls which operations are available via the /graphql endpoint, without a valid api key. These rules are processed before your @auth rules, and requests with an auth header must be whitelisted, as well as pass @auth rules.
– If an operation is not whitelisted for anonymous access, you may still call that graphql endpoint by passing Dg-Auth to any valid API key.
– We have introduced a new tab in the schema page to define the Anonymous access-related customizations. By default, Anonymous access is Enabled and customizations can be done by clicking Edit Permissions
– By Default the read-write access is enabled for all the types and lambda function customizations can be at each lower-level entity (type and lambda function)
Get Notified On Rate Limiting - From now on when a Starter backend is rate-limited UI will notify the limitation when the user lands in API explorer or Data Visualizer.
Bug Fixes:
Couple of bugs were fixed around lambdas and modify backends.
It appears to have defaulted to Off for my account.
The “Go to Docs” link has no information about this anywhere. I can only find information about this in this post here and on
There is very little explained.
What settings keep the operation the same as before this release? Off or On?
This wording at first made me think it was allowing anonymous access to administer my backend with them only needing the token instead of a login, but that is not at all what this is about.
This is very confusing and seems kind of abrupt with very little to no explanation as to exactly what it does and how to configure it.
We haven’t used the ClosedByDefault as is discussed in this issue, but I have many of the same concerns. Can we get some kind of heads up for changes like this?
The only place I saw this discussed anywhere was on the docs discuss page referenced above. Was there a RFC on this that helps explain all of the use cases and how this was built so we can understand it better if there are no docs yet for it?
Update: The other dev in my organization got to this before I did and switched it all off. I still would like to know what settings makes it operates the way it did before this release.
Update Again: Changing this takes ~10 minutes to apply? What?!?
If you leave anonymous access on then the backend will continue to behave as before. Existing backends should not be affected unless the rules were explicitly changed.
The anonymous access rules are applied against a token from Dgraph Cloud, and are applied before the @auth directive.
Well, we turned it off, not understanding it correctly at first. We have since turned it back on logged out waited 10 minutes and log back in and it shows to still be off. But at least it is working now like it is on, idk? Maybe there is a bug somewhere with updating the switch compared to what is actual?
We did change it because of the lack of documentation lead to a misunderstanding of what this actually did and we changed settings on the database we are prepping for production. (We have learned to not flip switches on production for new releases we don’t fully understand what they do)
I am assuming a Client key and Admin key have the same effect then in this situation. The wording gets confused now between all of the tokens/keys.
Is the API Key === “token”?
So a valid JWT “token” is only used after the API Key has been validated.
Does this efffect children too? (Afraid to test too much on a prepped production instance.)
If we have schema:
type User {
id: ID
posts: [Post] @hasInverse(field: "author")
}
type Post {
id: ID
author: User!
}
What would be the consequences of turning off anonymous access on User?
Could we no longer add a post because the author is required which an anonymous client couldn’t have?
Can we still query queryPost { author { id } } but just not queryUser { posts { id } }?
Usually I am directed to tests for new features that are not yet documented yet. Are there tests for this somewhere on Github?
@amaster507 Since you explicitly turned it OFF, When you turned it ON, you will need to give permission by selecting all checkbox (including lambda switch)
Thanks guys for the quick call to answer my questions!
This was confirmed as a bug in the UI. Refreshing the page still showed it Off. By clicking on the GraphQL Schema tab and then back on the Access tab it shows correctly as “On”
Yes. Right now the Client key and Admin key behave exactly the same to authenticate as non-anonymous access.
Yes.
No. Anonymous access only applies to the top level queries/mutations. If you restrict anonymous access to query Users, but allow anonymous access to Posts and posts have an edge to Users, then an anonymous query can still see the User data unless there are further auth rules that are unmet using the @auth directive.
If anonymous write permission has been allowed (as is by default) on the Post type, then a mutation to add/update a post with a new/existing user would still be allowed and processed unless further auth rules as defined by @auth add/update were in place preventing such action.
No. This is an Enterprise feature being offered to Dgraph Cloud (Slash GraphQL) customers.
