View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012328||mantisbt||api soap||public||2010-09-08 17:21||2018-05-20 07:00|
|Summary||0012328: Normalise access checks between the web interface and the SOAP API|
The SOAP API should use the exact same security settings that the web interface uses. Rather than duplicating, as it happens now, the checks should be encapsulated so that any further users of the core MantisBT API will benefit from them automatically.
|Tags||No tags attached.|
|related to||0012263||closed||rombert||No read access to issues with viewer rights over soap|
|related to||0017185||closed||vboctor||Read-only access via soap api should be available to VIEWER level|
|related to||0012517||closed||rombert||Users can view private bugs|
|related to||0013656||closed||rombert||Reporters have read/write access to existing data of other users|
|related to||0016993||closed||vboctor||Handler can be set without having appropriate access rights|
|related to||0022552||new||mc_issue_update doesn't honor project "resolved/read only" settings, adjusted threshholds, or "allow reporters to reopen"|
Reminder sent to: dhx, giallu, grangeway, jreese
In general, I would agree that access checks should be handled in the API, but any changes in this regard should be discussed with other devs to make sure this does not break some sort of known corner cases. Pinging the core devs on this issue for any discussions needed.
The thing that makes this difficult is context. Some thresholds only apply in certain contexts. For instance, bug_update.php will let people override workflow thresholds and restrictions when they're using the special abilities to assign an issue, provide feedback, etc.
I agree that we need to standardise access controls between SOAP API, MantisBT core and plugins. However I feel this is something that would ultimately require a lot of work creating an API that knows about context/overrides/etc. I think my changes to bug_update.php recently are an example of some of the complexities we'll face in designing an API layer to handle access controls and data validation before saving data to the database.
I understand that this requires a lot of work and attention, and a backing API. I raised it as a plan item, and I do not plan to start working on it (yet). There's a lot more until we get there :-).
I agree that consistency makes sense. The reason I had this extra threshold initially was really to protect against abuse by read-only VIEWERS. However, the same kind of abuse can be done by loading up MantisBT pages. Hence, I don't think it is really adding much value.
Initially, the API was mainly used to get tasks done by the team that owns the bug tracker, but overtime, scenarios expanded to allow clients and lower access users to use tools to interact with MantisBT other than the web UI.
To make this work properly we need a service API in MantisBT, which handles all of the concerns which are outside of data access, like
When we have that, we'll be able to have multiple clients of this API using it productively - the web UI and the SOAP UI. And then it will become feasible to have other clients, like a JSON API for rich clients .
Until then, duplicating access control between the web and the SOAP layers is extremely brittle.
Unassigned after a long time of inactivity.