Skip to main content

We currently only use the Web GUI on which we apply a maximum of 1 concurrent users per account, to prevent account sharing. This works great, except that we actually planning on developing an application on top of the rest API of Indicium.

What can happen is the following:

The user is logged in in the Web GUI. We have developed a plug-in for another piece of software to generate an export file. This export file can be exported in the plug-in and uploaded again in the Web GUI. But instead of all those manual actions of exporting, uploading (several clicks), we want to allow the user to directly upload that export file.

This is already possible using the Indicium OData API, so that's achieved. Problem is that when you are logged in in the Web GUI client, you will get a http 403 error in the Indicium plug-in on each call when you’re also logged in in the Web GUI, due to the concurrent access restriction. Off course this is by design I guess, but prevents us from add some really valuable extras to our software.

What we actually want is an exception for that specific application using Indicium. This application has a limited set of function calls (a few get calls for listing data and a post call to a task). Is this possible, or somehow to work around?

Hi René,

This is indeed currently not possible by design. The concurrent access system does not distinguish between different clients. Making an exception for Indicium will cause trouble in the future when the Universal GUI is used, as Indicium is used as back-end for Universal.

However, you can work around it in a different way.

You can create a second application in IAM without the concurrent access restrictions. This application uses the same project version and database but a different alias and only grant the users access to the role granting for the upload API. The plug-in will have to be updated to refer to the nonrestricted application.

In doing so, only the uploading will be unrestricted.

Hi Anne, thanks for the response. I'm trying the provided workaround, but I'm not sure how to deal with the following situation;

In order to do the call to the correct customer database(s), I retrieve the application id (or alias) via Indicium /iam/iam/i_ui_gui_appl. This only returns the applications which has a menu in it. The 'upload only' application I've only allowed to read a few tables and execute a task (subroutine), which should be sufficient. This 'upload only' application doesn't have a menu, as it's not necessary and I don't want to bother the user with 2 applications in the web gui. Is there a way to find out what the application id must be?

A workaround for that could be consistent application alias naming; e.g. having the regular application like 'customer' and the indicium one to 'customer-indicium', so a call to /iam/customer/my_table can be substituted with /iam/customer-indicium/my_table. But even if the both applications were there in i_ui_gui_appl, then you probably have the issue to 'which one to pick' to use for the 'upload only' application.

Except from the unknown application id/alias, it seems that it's working :grinning: .

The i_ui views only return information for the GUI’s. Since the auxiliary application is not an application with an user interface, it is not returned in this manner. If this was used to convey the application aliases to customers, this is unfortunate indeed.

I think the only option would be to use a naming convention here. For instance, if you want to call the upload api, you must use the -upload suffix in the URL. The customer-upload alias will never be returned from the /iam/iam/i_ui_gui_appl but can be derived from the regular customer application alias.

It will take some effort to support this naming convention in IAM and in communication with the customers, but I don’t see a better option at the moment.

Terms & ConditionsCookie settings