Access to ExtraTable data denied both in UI and API

Hi,

Does the user that you are doing this as/with have the following functional rights?

If you try it on the API using a system user, do you get the same error?

Hi,

yes, the user actually has every single right assigned to his role:

I am not sure what you mean with "If you try it on the API using a system user, do you get the same error?". What is a "system user"?

The user used for the API calls is a "normal" user (allowed to log in) with all rights. There seem to be no problems with other endpoints, it's only the ExtraTables that deny access.

Thanks and BR

Hi Holger,

There are also functional rights that deny certain functions ('Hide xxx screen', Requests in own categories vs all requests functional rights). So you shouldn't just move all functional rights to the "this role can" section.

System user are users you can create in the 'other users' section of the users page (You will need the license right 'System user administrator' to manage them), these users can't do anything in the SuperOffice GUI (except the admin) but do have complete rights on everything, they bypass any security or sentry mechanism. When using a system user you can test if this is a rights/access issue.

Hi David,

thanks alot for the explanation.

I created a system user:

but using that user for a POST-request to /api/v1/table/{table} yields the same result

{
    "Error": true,
    "ErrorType": "UnauthorizedAccessException",
    "Message": "You do not have access to the table, or it does not exist",
    "FriendlyMessage": "",
    "ErrorSource": "SuperOffice.Services.Implementation",
    "InnerError": {
        "ErrorType": "SoException",
        "Message": "Service call DatabaseTable.InsertRow failed with exception\r\nDatabaseTable.InsertRow",
        "ErrorSource": "SuperOffice.Services.Implementation",
        "InnerError": {
            "ErrorType": "UnauthorizedAccessException",
            "Message": "You do not have access to the table, or it does not exist",
            "ErrorSource": "SuperOffice.Services.Implementation",
            "InnerError": null
        }
    }
}

Other endpoints seem to work fine.

So, if I understood you correctly, this means that it's probably not an issue with user rights.

Since inserts do work using CRMScript, I guess that also eliminates the chance that it is some rights issue on the database level.

Is there some other (system-wide) setting to look for?

Thanks and BR

Hi,

The inserts done using CRMScript are directly done on database level, no through netserver like the REST API, so that is not a valid comparison.

If you get the same error when using a system user, it is indeed not an right issue. Do you have by chance a button 'Restart NetServer' when you go to the tables overview in service?

Could be this is a caching issue. (you can also manually force a refresh using the url <base url>/scripts/admin.fcgi?_sf=0&action=listExtraTables&restartNS=true

Hi David,

no, the button is hidden (and is used every time we make changes to our ExtraTables).

I was guessing that both CRMScript and Netserver use the same connection (and thus the same user with the same rights) to access the database, even if the Netserver might introduce an intermediate layer to check user rights etc.

Since the requests seem to fail at the Netserver level, is there some kind of log I could have a look at to see why the requests are being rejected?

Edit: I used the link you provided to restart the Netserver anyway - no changes unfortunately.

Thanks and BR

Hi,

Does your OnSite environment have a seperate NetServer installation for the API?

Hi David,

I was told it's all running on one machine with only one NetServer installation.

Thanks and BR

Hi,

Strange, you can try recycling the application pool in IIS to make sure there is no caching issue.

If you create a new extra table as a test and try to insert a row using the REST API, does that work?

Hi David,

we recycled the application pool (and for good measure restarted the site as well) but unfortunately the same problem persists.

Thanks and BR

Holger

Probably because ExtraTables are a Service thing, so there are some checks for a Service license we haven't removed.

This is a bug - a Sales user should be able to create + update extra fields without a Customer Service license.