[
https://issues.apache.org/jira/browse/SOLR-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18023303#comment-18023303
]
Christos Malliaridis edited comment on SOLR-17930 at 9/27/25 3:22 PM:
----------------------------------------------------------------------
"xBasic" auth is actually something the BasicAuthPlugin is already doing for
our current webapp. Specifically BasicAuthPlugin and MultiAuthPlugin handle the
webapp's ajax-requests differently. BasicAuthPlaugin specifically is passing
"xBasic" if it recognizes an Ajax-Request, just because of this issue.
So what I do in the PR and what I am adressing here is just extending the
workaround and adjusting its application to a wider set of use cases, so that
the new UI can work as expected under specific configuration. It is still
problematic when using only the BasicAuthPlugin, but it is not critical and the
new UI still works, just not as wanted.
This browser prompt for "Basic" challenge is actually the default behavior, so
it is not in our control to do anything against it. The only workarounds are to
either use different challenge (xBasic for example) under certain conditions,
send 403 instead of 401 response or do something completely custom. So I went
with what we had to avoid larger breaking changes.
Thanks for the comment btw, it helps clarifying and documenting special cases
and workarounds better. Of course, if there is any better solution to this that
I am not aware of I am happy to review it.
was (Author: JIRAUSER305622):
"xBasic" auth is actually something the BasicAuthPlugin is already doing for
our current webapp. Specifically BasicAuthPlugin and MultiAuthPlugin handle the
webapp's ajax-requests differently. BasicAuthPlaugin specifically is passing
"xBasic" if it recognizes an Ajax-Request, just because of this issue.
So what I do in the PR and what I am adressing here is just extending the
workaround and adjusting its application to a wider set of use cases, so that
the new UI can work as expected under specific configuration. It is still
problematic when using only the BasicAuthPlugin, but it is not critical and the
new UI still works, just not as wanted.
This browser prompt for "Basic" challenge is actually the default behavior, so
it is not in our control to do anything against it. The only workarounds are to
either use different challenge (xBasic for example) under certain conditions,
send 403 instead of 401 response or do something completely custom. So I went
with what we had to avoid larger breaking changes.
> Improve MultiAuthPlugin compatibility with BasicAuthPlugin
> ----------------------------------------------------------
>
> Key: SOLR-17930
> URL: https://issues.apache.org/jira/browse/SOLR-17930
> Project: Solr
> Issue Type: Improvement
> Components: Authentication
> Reporter: Christos Malliaridis
> Priority: Major
> Labels: authentication, new-ui, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Our current implementation of the MultiAuthPlugin is limited when used in
> combination with BasicAuthPlugin. The following scenarios describe the
> limitations:
> Consider this security.json:
> {code:json}
> {
> "authentication": {
> "class": "solr.MultiAuthPlugin",
> "schemes": [
> {
> "scheme": "Basic",
> "realm": "solr",
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
> },
> "forwardCredentials": false
> },
> {
> "scheme": "Bearer",
> "realm": "oauth",
> "class": "solr.JWTAuthPlugin",
> "blockUnknown": true,
> "wellKnownUrl":
> "http://localhost:3000/realms/master/.well-known/openid-configuration";,
> "clientId": "solr-jwt",
> "scope": "solr:admin",
> "redirectUris": "http://127.0.0.1:8983/solr/";,
> "authorizationFlow": "code_pkce"
> }
> ]
> }
> }
> {code}
> When MultiAuthPlugin is configured with BasicAuthPlugin and scheme "Basic",
> - browser clients that send ajax-requests (like old UI) will retrieve only
> the first plugin from schemes in MultiAuthPlugin, and if it is
> BasicAuthPlugin, the scheme is mapped to "xBasic"
> - browser clients that do not send ajax-requests (like new UI) will display a
> browser prompt (unwanted) but retrieve the entire list of auth headers
> The problem with this security.json is that there is no combination possible
> that provides the entire auth schemes in the "WWW-Authenticate" response
> headers, without a browser prompt showing up (which is a usability problem in
> the new UI).
The fix would likely be to use “scheme”: “xBasic” instead of
> “scheme”: “Basic” for BasicAuthPlugin. However, this is not working right
> now, because
- If clients send an authorized request with “Authenticate”:
> “Basic ...” the MultiAuthPlugin would not be able to find the plugin for the
> scheme, and
> - If clients send an authroized request with “Authenticated”: “xBasic ...”
> BasicAuthPlugin would fail because it expected “Basic ...”
> The current workaround for users is to write custom auth plugins, which is
> cumbersome and requires maintenance.
> h2. Proposal
> By allowing the MultiAuthPlugin looking up additionally for "xBasic" scheme
> if no "Basic" scheme is found, users would be able to use in clients "Basic"
> scheme even without an ajax-request, and configure the "xbasic" scheme in the
> MultiAuthPlugin with the BasicAuthPlugin as class. This would keep things
> secure with positive impact in the user experience in browser applications.
> h2. Benefits
> - Low impact of breaking changes
> - webapp (and existing clients) continue to work like before
> - MultiAuthPlugin is extended and supports “xBasic” as scheme for
> BasicAuthPlugin
> - Users can use “Basic” scheme for authorized requests by treating “xBasic”
> scheme like “Basic”
> - BasicAuthPlugin does not require any changes
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
