Hi!
When it comes to debugging documents and their associated document models, a clear error message is shown, identifying the field in the document which does not exist in the model.
In figuring out the exact access rights, based on different parameters, an access denied error does not show which field was attempted to be accessed for which the rights were not set. It makes development and potentially production issues not easy to debug.
Is improved logging already envisioned?
do you mean accessing whole documents or specific properties of them ?
If you set the log level to debug then you can see following logs:
2025-02-13 09:01:48,100 [http-nio-8082-exec-3][DEBUG][ity.spel.internal.UAAPolicyDecisionPoint][u:user1] - Permission [Model read permission] result is [false] in context[577864218]
2025-02-13 09:01:48,100 [http-nio-8082-exec-3][DEBUG][.a12.uaa.authorization.model.PolicyAware][u:user1] - Permission [Model read permission] executed with result=[false]
Their you can see the user and which UAA Policy was executed with which result. Is this something you want ?
Not quite. I created a new property permission policy with writing rights. For that, I have a list of fields that they are allowed to adapt. I only see failing policies logged (that indeed should fail), my new policy itself is not logged as failed (so that’s good).
It still returns failed permissions, though I don’t know whether this is due to a field I am missing in the allowance list. I currently cannot start Data Services locally in DEBUG-Logging level, because there is so much to log that my IDE crashes due to memory problems.
We implemented a logging to show you which fields/paths are failing during evaluation. This logging should be available if you’re using UAA version 8.1.0 or higher.
Our logging looks like:
Debug level: ("Property permission [%s] executed with result=[%s]; invalid properties: [%s]".formatted(name, result, invalidProperties));
Hope this helps.
Tuan Do
I am using 8.1.1, so that should fit. At which logging level are these logs available?
it’s debug level.
What is the reason behind the choice of making that logging at debug level? In my initial example, when a field in a document is not present in the model, you get an error logging. That this UAA issue is logged at debug level means that whenever an access issue happens in production, trying to get to the bottom of what is happening is very difficult.
We have different kind of logging:
Resource Authorization - Policy Execution → logging debug because this will definitely spam the whole logging since evaluation will different in different user. Normally if you have problem with this authorization we need to investigate. On the other hand, you’re able to switch the logging by implement policyExcuted
Property Authorization (I understand it’s your case) → Logging debug is also works as default here. On the other hand we had discussion again and would like to change the logging here to warning because:
That’s the suggestion from our side after discussion internally. Unfortunately it’s not implemented yet. We will do this improvement logging in upcoming releases.
Hope this helps,
Tuan Do
I think that is a wise decision indeed. 
Thanks!