Feature #18937
Updated by Tom Clegg over 2 years ago
As identified in #18887, the "secret" configured for the AnonymousUserToken is anything but, by definition.
The current configuration reference says:
<pre>
# Set AnonymousUserToken to enable anonymous user access. Populate this
# field with a random string at least 50 characters long.
AnonymousUserToken: ""
</pre>
If the AnonymousUserToken is left blank, certain UI elements are not shown in Workbench1 (e.g. the "Browse public projects" link, etc). In that case, Workbench1 also does not append it to the reader_tokens list with each API call (see #18936).
Since the actual secret in the AnonymousUserToken is basically meaningless, perhaps this configuration could be simplified to
<pre>
# Set AllowAnonymousUserAccess to enable anonymous user access. When enabled, data will
# still need to be shared with the anonymous user before it can be accessed without
# logging in. When disabled, no data can be accessed without logging in, regardless of
# being shared with the anonymous user.
AllowAnonymousUserAccess: false
</pre>
Instead of configuring/generating/passing/checking an "anonymous token", if AllowAnonymousUserAccess is enabled, we could
* accept incoming requests that have no token at all
* accept token "none" to mean no token, so clients that have logic like "ARVADOS_API_TOKEN environment variable must be set" can still be used
* always automatically add "anonymous user" to the set of user UUIDs when checking permissions permissions, if AllowAnonymousUserAccess is enabled.