vyommani commented on code in PR #1200:
URL: https://github.com/apache/ranger/pull/1200#discussion_r3901426178
##########
security-admin/src/main/java/org/apache/ranger/biz/SessionMgr.java:
##########
@@ -214,6 +220,18 @@ public UserSessionBase processSuccessLogin(int authType,
String userAgent, HttpS
logger.debug("Login Success: loginId={}, sessionId={},
details is null, epoch={}", currentLoginId, gjAuthSession.getId(),
cal.getTimeInMillis());
}
}
+
+ if (session != null) {
Review Comment:
This block runs whenever `processSuccessLogin()` takes the
`newSessionCreation` path which fires on the *first request of any new
HttpSession* for an authenticated principal, not specifically on a UI login.
For SPNEGO/Kerberos/trusted-proxy auth there's no discrete "login" step, so any
non-interactive caller that doesn't reuse a session cookie (e.g. a `kinit`+curl
script, `RangerClient` usage, or any authenticated REST call outside the
download-URL allowlist in `isPluginOrSecureDownloadRequest()`) will consume a
slot in the same per-user quota as the browser UI session, and can evict the
admin's actual browser tab.
The JIRA describes this as limiting *UI* sessions specifically. As written,
it limits "any non-download authenticated session." Worth either:
a--> restricting this to actual UI traffic (user-agent check, a UI
marker/referer, or scoping to specific URL prefixes), or
b--> adding a second property to opt API-style sessions in/out of the quota
(default: excluded), or
c--> if the current broader scope is intentional, updating the
JIRA/description to say so explicitly so this doesn't surprise anyone running
automation against the same login ID.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
