Idea #2659
Updated by Tom Clegg over 10 years ago
This has two parts: # Implement a special "Anonymous" group and user #* Created automatically, much like the "system group". uuid = @xyzzy-j7d0g-anonymouspublic@? #* In permission checks, make sure @anonymous_group_uuid@ is always in the list of readable groups. #* This should produce the desired result if someone shares an object with the Anonymous group -- at least for users who are logged in. # Provide a mechanism for clients to get "anonymous" privileges without using the usual OAuth/SSO procedure. #* Add apiserver script to generate Could simply use a well-known token for the special anonymous user (like fifty "X" characters). #* Careful in API server not to let an anonymous user modify its own User object (or anything else normally allowed by permission system). Setting token scopes to @["GET /"]@ should be enough? #* Add Workbench configuration item for "anonymous API server has to decide whether to say "please log in" or "just do stuff that anonymous user token". (When this is nil, just use the current behavior.) can do". No token = anonymous? #* Workbench has to act a bit differently when deciding to show a login page, redirect to authentication procedure, or just proceed as anonymous user. E.g., bookmark a private page, log out, go back to the private page → show "not found or not authorized" page, and provide an option to log in. #* Workbench should avoid showing "create new folder" links when operating in anonymous mode. (Probably need to fix some assumptions that "everyone can do X", and improve the "editable?" and "creatable?" methods so they return correct answers when current_user is the anonymous user.)