[
https://issues.apache.org/jira/browse/SOLR-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806914#comment-16806914
]
Jason Gerlowski commented on SOLR-13344:
----------------------------------------
Your PR looks good to me such as it is. I was worried about str comparison on
the path being brittle, but I'm reassured that we already do this for
authentication.
My only question on the code itself: For authentication, we check against the
paths {{/}} and {{/solr/}}, but in your PR you're only checking against {{/}}.
Is there a reason for that?
----
As for the functionality of your patch, I tested it quickly myself and can
confirm that I am prompted for credentials by the expected "Basic Auth" splash
screen when I first load the admin UI, which is an improvement. And when I
provide credentials for an admin user, the admin UI appears as expected.
But if I provide credentials for a user with readonly permissions (read,
schema-read, config-read, core-admin-read, collection-admin-read), the Admin UI
appears, but looks pretty crippled (see attached screenshot). This isn't a bug
per-se...the logged-in user just didn't have the right permissions. And really
it has nothing to do with the login-page...this same behavior happens in Solr
versions before the login screen was introduced.
But now that we have a nice page that prompts the user about logging in, maybe
it's worth adding a short warning about this situation to the text there?
Something like: {{Solr's Admin UI interacts with Solr using its public APIs.
When rule-based authorization is in use, login users not authorized to access
the full range of these APIs may see some sections of the UI that appear blank
or "broken". For best results, Solr's Admin UI should only be accessed by
logins with full API access.}}. Maybe that's too wordy...
Just throwing that out there as an idea. The patch has my +1 with or without
it.
> Admin UI inaccessible with RuleBasedAuthorizationPlugin
> -------------------------------------------------------
>
> Key: SOLR-13344
> URL: https://issues.apache.org/jira/browse/SOLR-13344
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Authentication
> Affects Versions: 7.7, 8.0
> Reporter: Märt
> Assignee: Jan Høydahl
> Priority: Major
> Fix For: 8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SOLR-7896 made some changes to the admin ui login. After the changes I can no
> longer log in at all.
> I'm running standalone solr 7.7 (same with 8.0) with the following
> security.json:
> {code}
> {
> "authentication": {
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
> },
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {
> "name": "all",
> "role": "admin"
> }
> ],
> "user-role": {
> "solr": "admin"
> }
> }
> }
> {code}
> Opening the UI at http://localhost:8080/solr/ shows an error page with 401.
> The login page is not displayed because of the "all" permission being
> required. The browser's basic auth popup is not shown because the
> WWW-Authenticate header is not present. Changing the
> RuleBasedAuthorizationPlugin required permission from "all" to
> "security-edit" makes the login page appear.
> The bug can be reproduced as follows:
> # unpack solr-8.0.0.zip
> # copy the security.json example from
> https://lucene.apache.org/solr/guide/7_7/basic-authentication-plugin.html
> into server/solr/ and replace "name":"security-edit" with "name":"all"
> # start with bin/solr -f -p 8080
> # open http://localhost:8080/
> The bug was discussed on solr-user list
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201903.mbox/%3C7629BDDD-3D22-4203-9188-0E0A8DCF2FEE%40cominvent.com%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
