Solved

Execute API as IFSINFO

  • 22 April 2022
  • 2 replies
  • 299 views
J
Rank
Userlevel 4
Badge +9

I need to do a select statement that calls a number of API’s that are not available under the schema that I am logged in under. Basically I have a select that selects from tables and views that I have access to under the login I am using (IFSINFO). But there are some lines that call API’s that are only available under a different login (IFSAPP).

If I comment out the lines that call these API’s the select works fine. But if I leave one of them uncommented the select brings back nothing. I have tried logging in as IFSAPP and granting Execute on user IFSINFO to those packages but when I log back in as IFSINFO the select comes back with no rows. It doesn’t give an insufficient privilege error.

I am thinking that the API selects from tables/views that IFSINFO does not have the select rights on. Is there a way that execute can be granted to IFSINFO on an API (and at the same time grant privileges' on whatever views or tables that are referenced in that API)?

icon

Best answer by NickPorter 22 April 2022, 21:03

View original

2 replies

NickPorter
Rank
Userlevel 6
Badge +18

I really wouldn’t recommend doing what you’re trying to do here, as opening up access to IFSAPP-owned objects that are not normally granted to IFSINFO could result in IALs revealing more than they should to standard users who use them.

Depending on what the underlying tables/views are you might actually find it is not really a permission issue, rather it could be a ‘filter’ issue, e.g. if a view is using a company filter in it’s definition that IFSINFO does not belong to then it may return no results even if it has access to the objects.

Technically there wouldn’t be anything to stop you from granting access to everything but I really wouldn’t go down that road, especially if granting it to a standard IFS account that is intended for specific purposes.

Nick

 

J
Rank
Userlevel 4
Badge +9

I really wouldn’t recommend doing what you’re trying to do here, as opening up access to IFSAPP-owned objects that are not normally granted to IFSINFO could result in IALs revealing more than they should to standard users who use them.

Depending on what the underlying tables/views are you might actually find it is not really a permission issue, rather it could be a ‘filter’ issue, e.g. if a view is using a company filter in it’s definition that IFSINFO does not belong to then it may return no results even if it has access to the objects.

Technically there wouldn’t be anything to stop you from granting access to everything but I really wouldn’t go down that road, especially if granting it to a standard IFS account that is intended for specific purposes.

Nick

 

Yeah you could be right; it might not be anything to do with privileges and could be because IFSINFO is not part of a certain user group or something similar. It could take ages to find that out though and I don’t have ages. 

Reply


Terms & ConditionsCookie settings