I don't understand what you mean with "Are these three not supposed to be the same?". Yes, from a java perspective it's always an instance of a ResourceResolver. From the permissions attached to the resourceResolver it depends.
In case 1 the permissions are implicitly clear, as you are using an admin session. In case 2 and 3 the permissions attached to the session can be managed externally and explicitly.
All of them serve the same purpose but obviously differ in how and when to use. I will try to explain though
Resource Resolver Via
1) Administrative Null - DEPRECATED
From your code; Line 77 resourceResolverFactory.getAdministrativeResourceResolver(null); This was the old way of accessing the repository via code. When we used to code back in those days, even if the user had restricted access to the content, with this code , from back-end we used to gain full access to the repository. So you can obviously understand the security loophole it had. Because of such security issues , this was deprecated . So should not be used anymore . See the doc here
2) Service User
To address all the security issues caused by accessing the Resource Resolver via getAdministrativeResourceResolver(null) ; this new method was introduced, which mandates you to have a dedicated user ( Should be a SYSTEM USER)with restricted permissions. Using
method ; you can get the resourceResolver only if the user has the privilege to access the content you are trying to access via backend. If the user doesn't have the required privilege , it will return null. Please find the official doc here
3) From Request
As ravi mentioned , it is specific to the current request. The resolver resolver out of this way will have the permissions as same as the user requesting this. A little explanation on getting resourceResolver via request from the web is found here
Hope this helps. Let me know if you are still unclear. If there is any discrepancies in my response , please feel free to correct me 🙂 .
1. Get an administrative resource resolver -- will have admin access even without passing any credentials and depreciated as it is not good practice. As it will give full access to add/delete/modify to the nodes for all requests.
3. Resource resolver from the request in a servlet (hit on author) after providing admin credentials as "basic authentication" say in postman. -- Will have the access of the logged in user, if user is admin, we can get admin access from request or if user is not having delete access, performing delete will throw exception