Kinda wish they went with a model other than “we let you do everything unless you define at least one item in each category.”
What issue are you having with scope? The idea is to attach a limiting scope to a user for integration, security, etc. If they have no scope, it’s going to default to the menu or field level or BO security otherwise.
I’m issuing an API key which is meant to be used for, basically, one thing and one thing only. In this case, it happens to be a function. I still have to declare something in the Services and BAQ groups to limit access. So I used the workaround above. I’d have preferred a model like the Menu, where you can blacklist except otherwise indicated.
For integration, the default-deny is a much better approach. Menu security is kind of a joke anyways, but for integration this is the better model. So, you surgically define the services/baqs/functions/whatever it needs to use and then it is definitely isolated to those. Plus, it’s documented about what it can access and perform.
Except it doesn’t default-deny. Until I built the phony BAQ, and added it to the scope, it was default allowing access to all BAQ’s. Ditto on services until I added ABCCode.GetByID.
huh. That has not been my experience.
Hmm. I put this here because I thought it was a joke. If this is an actual bug…it might have to move somewhere serious. I don’t see anything in the 10.2.700 changelogs.
Let me fire up Epicor and see what’s going on. It’s been my experience that if there is an access scope attached to the user and that access scope doesn’t explicitly allow the baq/svc/function, it will not allow access to it when using those credentials to perform the request. But what you’re saying is it allows EVERYTHING unless you define an explicit allow, then it only allows the defined allow and denies everything else?
Ok this correlates with that I was thinking. I set up an access scope with no permissions attached. Then, I added this scope to the integration user. I try to hit the BAQ svc endpoint with a simple query that does not have anything else interesting about it (no Security ID, for instance) from Postman
Keep in mind the test below is with v1 API (credentials only) but I’ll demo both ways and show they work as described.
(my snipping tool is acting up, otherwise I’d have cleaner screenshots)
400 Forbidden
If I add the BAQ to the Access Scope, it now allows me:
200 OK
Test 2 is v2 (API Key + Credentials)
Kept the BAQ permissions on the scope and now accessing API with key + creds:
Then removed the BAQ from the scope:
Did you verify you are passing your request with the proper credentials and that the user account you are using has the proper access scope defined on it and that the API key you are using has your preferred Access Scope attached?