View Issue Details

IDProjectCategoryView StatusLast Update
0012328mantisbtapi soappublic2018-05-20 07:00
Reporterrombert Assigned To 
Status acknowledgedResolutionopen 
Product Version1.2.2 
Summary0012328: 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.

TagsNo tags attached.


related to 0012263 closedrombert No read access to issues with viewer rights over soap 
related to 0017185 closedvboctor Read-only access via soap api should be available to VIEWER level 
related to 0012517 closedrombert Users can view private bugs 
related to 0013656 closedrombert Reporters have read/write access to existing data of other users 
related to 0016993 closedvboctor 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" 




2010-09-08 17:42

reporter   ~0026634

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.



2010-09-08 20:28

reporter   ~0026638

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.



2010-09-09 01:40

reporter   ~0026639

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 :-).



2013-11-03 16:21

manager   ~0038432

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.



2013-11-08 05:06

reporter   ~0038507

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

  • authorization
  • logging
  • history

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.



2018-05-20 07:00

developer   ~0059876

Unassigned after a long time of inactivity.