ODATA BAQ Security Access Help

[byalb (Brian Byal)]

Howdy howdy -

We have a scenario where users are using Excel to make ODATA BAQ calls and some have found that they can see ALL BAQs by using the URL below. Some users are modifying their original call with the BAQs they are finding from said URL.
hhttps://redacted.local/redacted/api/v1/BaqSvc

Is there a way to prevent unauthorized users from accessing this link?

Are there Epicor logs to determine who are making these calls?

Our business case is we have a BAQ for timeclock punches with a parameter that accepts the Epicor client session username. In Excel, users have found they can modify the URL call with any username to retrieve other individuals’ time punches, which they should not be doing. /sigh
Assigning a Security ID to the BAQ would not work as this BAQ needs to be open to all.

Open to any suggestions.

Thanks!

[Mark_Wonsil]

TL;DR; Use BAQ Security.

Explanation on BAQ Security in relation to Active Home Page

Hi! Hoping someone can help me understand BAQ security. We’ve never set security on any BAQs because it is just me and one other admin that has access to the Business Activity Query menu. We are about to upgrade to 2021.2. While setting up some default home page layouts, I noticed that any user could figure out how to add a BAQ widget and see financials, etc. I need to fix this quickly!!! Is there a way to mass update security on all BAQs? I don’t see an option in DMT. I’m surprised we would …

[CSmith (Clint Smith)]

FYI, they should only have access to whatever their API key allows are you using a global API key or something?

[byalb (Brian Byal)]

Thanks for the suggestion! Maybe I am not looking at the BAQ Security correctly, but this BAQ needs to be accessible to all.

Our Time Clock BAQ Dashboard passes in the logged in session username into the BAQ to retrieve the user’s time punches. However, an external call, such as Excel ODATA, the username parameter can be manipulated to be any user in the call itself, which gives unauthorized access to time punches that are not their own.

[byalb (Brian Byal)]

Thanks for the comment. I made a mistake in my original post. The Excel call is happening via v1, which does not require API key (whereas v2 does). In Excel, they are only required to pass in Epicor login credentials to connect when using v1.

[CSmith (Clint Smith)]

Well, you can use v2 for OData calls in Excel
AFAIK, you could also setup a BPM to log the user, IP and fairly certain also the BAQ they are accessing. Yes v1 is good for certain thing and not so much for others…
Security=NOT SO MUCH

[CSmith (Clint Smith)]

@byalb

an external call, such as Excel ODATA, the username parameter can be manipulated to be any user in the call itself,

You could parameterize the data better with a locked sheet and/or create a login form to pass their credentials to the API for the OData call via M.

[BenWheeldon]

Instead of passing the username in as a parameter. Why not add a table criteria in the BAQ using the BAQ constant of the user?

That way it will run for only the logged in user without needing to pass it in as a parameter.

[byalb (Brian Byal)]

This was it! Had no idea about these BAQ constants. Many thank yous.