View Issue Details

IDProjectCategoryView StatusLast Update
0017236mantisbtapi soappublic2014-05-03 16:52
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.2.17 
Summary0017236: Support exposing some configuration anonymously
Description

There are scenarios where a subset of the configuration should be exposed anonymously. At this point we only expose the version number anonymously, but everything else requires a valid login to use the mc_config_get().

For example, if a client is to implement a login page, they don't have authentication yet, but they need to know information like:

  • Does instance support anonymous login?
  • What is the username of the anonymous user?
  • Does instance allow signup?
  • Logo url for the instance?
  • Show version and version suffix
  • Fallback language
  • Window Title

So similar to config_is_private(), we will need config_is_anonymous() and for the ones that match that, we should return them without requiring authentication.

There are three options:

  1. mc_config_get_anonymous() returns all anonymous configs in one call.
  2. mc_config_get_anonymous( $p_config_name )
  3. mc_config_get( $p_username, $p_password, $p_config_name ) - just ignore username / password when config_name is anonymous config.

For 1 and 2, we can return:
a. Structured data so that clients can create a proxy.
b. A property bag.

The easiest solution is 3. My preferred solution is 1 + a.

TagsNo tags attached.

Activities

rombert

rombert

2014-04-23 10:51

reporter   ~0040135

How about

mc_config_get_all( $p_username, $p_password )

with proper access level checks? This would retrieve all configs available to the user, and take into account anonymous access if enabled. The advantage is that we keep the client API minimal.

vboctor

vboctor

2014-05-03 16:52

manager   ~0040208

OK, so we are on the same page as far as retrieving N configs at a time and retrieving them anonymously.

The issue with the approach you proposed is that it is inconsistent with the rest of API in that it supports anonymous access even if the instance doesn't allow it. This could be confusing.

There is also no upside for giving more details in the anonymous case since typically this API will be used pre-login, so you will be providing potentially more data than needed in the case of instances that support anonymous, since some of these configs will change once the user logs in.

Hence, I think we should have the following:

  • mc_config_get_instance() - returns all the configs that make sense before a user is logged in. -- I'm open for a better name for this API.
  • mc_config_get_all( $p_username, $p_password ) - return all configs for the specific user or anonymous if enabled.

Note that for get_all, we will have to initially filter out configs that we can't serialize until the serialization for arrays is sorted out.