rombert commented on code in PR #78:
URL:
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/78#discussion_r941399874
##########
src/main/java/org/apache/sling/resourceresolver/impl/console/ResourceResolverWebConsolePlugin.java:
##########
@@ -255,19 +278,42 @@ protected void doPost(HttpServletRequest request,
// finally redirect
final String path = request.getContextPath() + request.getServletPath()
+ request.getPathInfo();
- final String redirectTo;
+ String redirectTo;
if (msg == null) {
redirectTo = path;
} else {
redirectTo = path + '?' + PAR_MSG + '=' + encodeParam(msg) + '&'
+ PAR_TEST + '=' + encodeParam(test);
+ if ( user != null && user.length() > 0 ) {
+ redirectTo += '&' + PAR_USER + '=' + encodeParam(user);
+ }
}
response.sendRedirect(redirectTo);
}
+ private ResourceResolver
getImpersonatedResourceResolver(HttpServletRequest request, final String user)
+ throws LoginException {
+
+ // resolver is set by the auth.core bundle in case of successful
authentication, so it should
+ // always be there
+ Object resolverAttribute =
request.getAttribute(AuthenticationSupport.REQUEST_ATTRIBUTE_RESOLVER);
+ if ( !(resolverAttribute instanceof ResourceResolver) ) {
+ throw new IllegalArgumentException("No " +
ResourceResolver.class.getSimpleName() + " found in request, unable to proceed
with impersonation");
Review Comment:
@kwin suggested that we use an admin resolver instead (and include the
bundle in the allow list ). If we would stop looking up the ResourceResolver in
the request attribute, would it solve this issue?
https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/78#discussion_r941353233
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
