You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Terry Steichen <te...@net-frame.com> on 2018/03/13 16:46:41 UTC
Continuing Saga of Authorization on 6.6.0
I switched solr from standalone to cloud and created the two collections
(emails1 and emails2).
I was able to create a basic set of credentials via the curl-based
API's. I could create users, and toggle the blockUnknown property
status. However, the system refused to allow me to delete a user, or to
set a permission.
Here are the curl commands (with *terry:admin* as admin credentials) and
results:
*succeeded in setting blockUnknown property (verified by
admin/authentication dump):*
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{
"set-property": {"blockUnknown" : true}}'
*succeeded in adding a user (verified by admin/authentication dump):*
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{
> "set-user": {"lanny" : "hawaii"}}'
*succeeded in changing lanny's password (verified by
admin/authentication dump):*
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{
"set-user": {"lanny" : "hawaii_five_o"}}'
*failed to delete a user:*
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{
"delete-user": {"lanny"}}'
{
"responseHeader":{
"status":500,
"QTime":1},
"error":{ "msg":"Expected key,value separator ':': char=},position=26
BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
[terry here: plus a very long stack trace}
*failed to set a permission: *
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{"set-permission" :
{"name":"collection-admin-edit", "role":"admin"}}'
{
"responseHeader":{
"status":0,
"QTime":2},
"errorMessages":[{
"set-permission":{
"name":"collection-admin-edit",
"role":"admin"},
"errorMessages":["Unknown operation 'set-permission' "]}]}
This really makes no sense at all (or, I'm really losing it - always a
distinct possibility). It's almost as if half of the documented
parameters must have been changed, though I can't find any references to
any such changes.
I confess I'm about to just give up and find some other route to go.
Terry
On 03/12/2018 11:15 PM, Shawn Heisey wrote:
> On 3/12/2018 8:39 PM, Terry Steichen wrote:
>> I'm increasingly of the view that Solr's authentication/authorization
>> mechanism doesn't work correctly in a _standalone_ mode. It was present
>> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
>> it was supposed to be available in standalone mode too. It seems to
>> partly work (when using the built-in permissions), but does not seem to
>> work with customized, core-specific permissions.
>
> I suspected based on your last message that the authorization feature
> might only work correctly in SolrCloud. The entire authentication
> feature was designed for SolrCloud. Version 6.5 brought the
> security.json file to standalone mode. This was LONG after the
> feature was introduced in 5.2 and had a LOT of bugs fixed in the three
> 5.3.x releases.
>
> I just found the section in the documentation confirming what I
> suspected.
>
> https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
>
>
> There is a note here that says "The authorization plugin is only
> supported in SolrCloud mode. Also, reloading the plugin isn’t yet
> supported and requires a restart of the Solr installation (meaning,
> the JVM should be restarted, not simply a core reload)." The 6.6
> documentation contains the same note that you can see here in the
> latest docs.
>
> I have no idea how hard it would be to extend the authorization plugin
> to support standalone cores as well as collections. I imagine that if
> it were easy, it would have been done already.
>
> Thanks,
> Shawn
>
>
Re: Continuing Saga of Authorization on 6.6.0
Posted by Chris Ulicny <cu...@iq.media>.
You can see the security.json file in the admin console if you go to the
Cloud tab, and then select Tree. It should be visible there without having
to navigate directly into zookeeper.
Best,
Chris
On Tue, Mar 13, 2018 at 1:26 PM Terry Steichen <te...@net-frame.com> wrote:
> Chris, many, many thanks. From a quick check, those changes seem to
> work. I think I'm getting too old to differentiate between brackets and
> curly braces. I'll get back on track and see if I can (finally) set
> this up right.
>
> What also puzzles me is that I can't find any "security.json" file.
> Clearly, solr is persistently keeping track of the
> authentication/authorization information, but I don't see where. I
> suppose it might be kept in zookeeper (which perhaps survives solr
> restarts - but I don't know). Any insights on that?
>
> Terry
>
> On 03/13/2018 01:01 PM, Chris Ulicny wrote:
> >> *failed to delete a user:*
> > "delete-user" is expecting an array of users in the json, so the data
> > should be: {"delete-user": ["lanny"]}
> >
> >
> >> *failed to set a permission: *
> > There are separate endpoints for authorization and authentication. You
> > should use ".../solr/admin/authorization" for the permissions instead of
> > "../solr/admin/authentication"
> >
> https://lucene.apache.org/solr/guide/7_2/rule-based-authorization-plugin.html#manage-permissions
> >
> > Disclaimer: I've never worked with 6.6, but I've not noticed any big
> > differences between the security for our 6.3 deployments and the 7.X
> ones.
> >
> > Best,
> > Chris
> >
> > On Tue, Mar 13, 2018 at 12:47 PM Terry Steichen <te...@net-frame.com>
> wrote:
> >
> >> I switched solr from standalone to cloud and created the two collections
> >> (emails1 and emails2).
> >>
> >> I was able to create a basic set of credentials via the curl-based
> >> API's. I could create users, and toggle the blockUnknown property
> >> status. However, the system refused to allow me to delete a user, or to
> >> set a permission.
> >>
> >> Here are the curl commands (with *terry:admin* as admin credentials) and
> >> results:
> >>
> >> *succeeded in setting blockUnknown property (verified by
> >> admin/authentication dump):*
> >>
> >> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{
> >> "set-property": {"blockUnknown" : true}}'
> >>
> >> *succeeded in adding a user (verified by admin/authentication dump):*
> >>
> >> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{
> >>> "set-user": {"lanny" : "hawaii"}}'
> >> *succeeded in changing lanny's password (verified by
> >> admin/authentication dump):*
> >>
> >> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{
> >> "set-user": {"lanny" : "hawaii_five_o"}}'
> >>
> >> *failed to delete a user:*
> >>
> >> curl --user terry:admin
> http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{
> >> "delete-user": {"lanny"}}'
> >> {
> >> "responseHeader":{
> >> "status":500,
> >> "QTime":1},
> >>
> >> "error":{ "msg":"Expected key,value separator ':': char=},position=26
> >> BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
> >> [terry here: plus a very long stack trace}
> >>
> >> *failed to set a permission: *
> >>
> >> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{"set-permission" :
> >> {"name":"collection-admin-edit", "role":"admin"}}'
> >> {
> >> "responseHeader":{
> >> "status":0,
> >> "QTime":2},
> >> "errorMessages":[{
> >> "set-permission":{
> >> "name":"collection-admin-edit",
> >> "role":"admin"},
> >> "errorMessages":["Unknown operation 'set-permission' "]}]}
> >>
> >>
> >> This really makes no sense at all (or, I'm really losing it - always a
> >> distinct possibility). It's almost as if half of the documented
> >> parameters must have been changed, though I can't find any references to
> >> any such changes.
> >>
> >> I confess I'm about to just give up and find some other route to go.
> >>
> >> Terry
> >>
> >>
> >> On 03/12/2018 11:15 PM, Shawn Heisey wrote:
> >>> On 3/12/2018 8:39 PM, Terry Steichen wrote:
> >>>> I'm increasingly of the view that Solr's authentication/authorization
> >>>> mechanism doesn't work correctly in a _standalone_ mode. It was
> present
> >>>> in the cloud mode for quite a few versions back, but as of 6.0.0 (or
> so)
> >>>> it was supposed to be available in standalone mode too. It seems to
> >>>> partly work (when using the built-in permissions), but does not seem
> to
> >>>> work with customized, core-specific permissions.
> >>> I suspected based on your last message that the authorization feature
> >>> might only work correctly in SolrCloud. The entire authentication
> >>> feature was designed for SolrCloud. Version 6.5 brought the
> >>> security.json file to standalone mode. This was LONG after the
> >>> feature was introduced in 5.2 and had a LOT of bugs fixed in the three
> >>> 5.3.x releases.
> >>>
> >>> I just found the section in the documentation confirming what I
> >>> suspected.
> >>>
> >>>
> >>
> https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
> >>>
> >>> There is a note here that says "The authorization plugin is only
> >>> supported in SolrCloud mode. Also, reloading the plugin isn’t yet
> >>> supported and requires a restart of the Solr installation (meaning,
> >>> the JVM should be restarted, not simply a core reload)." The 6.6
> >>> documentation contains the same note that you can see here in the
> >>> latest docs.
> >>>
> >>> I have no idea how hard it would be to extend the authorization plugin
> >>> to support standalone cores as well as collections. I imagine that if
> >>> it were easy, it would have been done already.
> >>>
> >>> Thanks,
> >>> Shawn
> >>>
> >>>
> >>
>
>
Re: Continuing Saga of Authorization on 6.6.0
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/13/2018 12:00 PM, Terry Steichen wrote:
> So, Shawn, every time zookeeper gets shut down (intentionally or
> otherwise), I have to recreate the credentials and permissions via a set
> of API calls? Is there some way to have it save and read that stuff
> from disk?
If your ZK ensemble doesn't keep that info around through restarts, then
it is badly configured. The ZK database should be persistent. They do
have a concept of an ephemeral node, and I think Solr does use that
feature, but it should NOT be in use for the majority of what Solr puts
in ZK.
Thanks,
Shawn
Re: Continuing Saga of Authorization on 6.6.0
Posted by Terry Steichen <te...@net-frame.com>.
So, Shawn, every time zookeeper gets shut down (intentionally or
otherwise), I have to recreate the credentials and permissions via a set
of API calls? Is there some way to have it save and read that stuff
from disk?
Terry
On 03/13/2018 01:51 PM, Shawn Heisey wrote:
> On 3/13/2018 11:25 AM, Terry Steichen wrote:
>> What also puzzles me is that I can't find any "security.json" file.
>> Clearly, solr is persistently keeping track of the
>> authentication/authorization information, but I don't see where. I
>> suppose it might be kept in zookeeper (which perhaps survives solr
>> restarts - but I don't know). Any insights on that?
> Yes, with SolrCloud, the security.json file is kept in zookeeeper.
> Almost all of the configuration for SolrCloud is in zookeeper, so it can
> affect any server in the cloud. The only usual exception is solr.xml,
> and even that file CAN be in zookeeper.
>
> Thanks,
> Shawn
>
>
Re: Continuing Saga of Authorization on 6.6.0
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/13/2018 11:25 AM, Terry Steichen wrote:
> What also puzzles me is that I can't find any "security.json" file.
> Clearly, solr is persistently keeping track of the
> authentication/authorization information, but I don't see where. I
> suppose it might be kept in zookeeper (which perhaps survives solr
> restarts - but I don't know). Any insights on that?
Yes, with SolrCloud, the security.json file is kept in zookeeeper.
Almost all of the configuration for SolrCloud is in zookeeper, so it can
affect any server in the cloud. The only usual exception is solr.xml,
and even that file CAN be in zookeeper.
Thanks,
Shawn
Re: Continuing Saga of Authorization on 6.6.0
Posted by Terry Steichen <te...@net-frame.com>.
Chris, many, many thanks. From a quick check, those changes seem to
work. I think I'm getting too old to differentiate between brackets and
curly braces. I'll get back on track and see if I can (finally) set
this up right.
What also puzzles me is that I can't find any "security.json" file.
Clearly, solr is persistently keeping track of the
authentication/authorization information, but I don't see where. I
suppose it might be kept in zookeeper (which perhaps survives solr
restarts - but I don't know). Any insights on that?
Terry
On 03/13/2018 01:01 PM, Chris Ulicny wrote:
>> *failed to delete a user:*
> "delete-user" is expecting an array of users in the json, so the data
> should be: {"delete-user": ["lanny"]}
>
>
>> *failed to set a permission: *
> There are separate endpoints for authorization and authentication. You
> should use ".../solr/admin/authorization" for the permissions instead of
> "../solr/admin/authentication"
> https://lucene.apache.org/solr/guide/7_2/rule-based-authorization-plugin.html#manage-permissions
>
> Disclaimer: I've never worked with 6.6, but I've not noticed any big
> differences between the security for our 6.3 deployments and the 7.X ones.
>
> Best,
> Chris
>
> On Tue, Mar 13, 2018 at 12:47 PM Terry Steichen <te...@net-frame.com> wrote:
>
>> I switched solr from standalone to cloud and created the two collections
>> (emails1 and emails2).
>>
>> I was able to create a basic set of credentials via the curl-based
>> API's. I could create users, and toggle the blockUnknown property
>> status. However, the system refused to allow me to delete a user, or to
>> set a permission.
>>
>> Here are the curl commands (with *terry:admin* as admin credentials) and
>> results:
>>
>> *succeeded in setting blockUnknown property (verified by
>> admin/authentication dump):*
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{
>> "set-property": {"blockUnknown" : true}}'
>>
>> *succeeded in adding a user (verified by admin/authentication dump):*
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{
>>> "set-user": {"lanny" : "hawaii"}}'
>> *succeeded in changing lanny's password (verified by
>> admin/authentication dump):*
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{
>> "set-user": {"lanny" : "hawaii_five_o"}}'
>>
>> *failed to delete a user:*
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{
>> "delete-user": {"lanny"}}'
>> {
>> "responseHeader":{
>> "status":500,
>> "QTime":1},
>>
>> "error":{ "msg":"Expected key,value separator ':': char=},position=26
>> BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
>> [terry here: plus a very long stack trace}
>>
>> *failed to set a permission: *
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{"set-permission" :
>> {"name":"collection-admin-edit", "role":"admin"}}'
>> {
>> "responseHeader":{
>> "status":0,
>> "QTime":2},
>> "errorMessages":[{
>> "set-permission":{
>> "name":"collection-admin-edit",
>> "role":"admin"},
>> "errorMessages":["Unknown operation 'set-permission' "]}]}
>>
>>
>> This really makes no sense at all (or, I'm really losing it - always a
>> distinct possibility). It's almost as if half of the documented
>> parameters must have been changed, though I can't find any references to
>> any such changes.
>>
>> I confess I'm about to just give up and find some other route to go.
>>
>> Terry
>>
>>
>> On 03/12/2018 11:15 PM, Shawn Heisey wrote:
>>> On 3/12/2018 8:39 PM, Terry Steichen wrote:
>>>> I'm increasingly of the view that Solr's authentication/authorization
>>>> mechanism doesn't work correctly in a _standalone_ mode. It was present
>>>> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
>>>> it was supposed to be available in standalone mode too. It seems to
>>>> partly work (when using the built-in permissions), but does not seem to
>>>> work with customized, core-specific permissions.
>>> I suspected based on your last message that the authorization feature
>>> might only work correctly in SolrCloud. The entire authentication
>>> feature was designed for SolrCloud. Version 6.5 brought the
>>> security.json file to standalone mode. This was LONG after the
>>> feature was introduced in 5.2 and had a LOT of bugs fixed in the three
>>> 5.3.x releases.
>>>
>>> I just found the section in the documentation confirming what I
>>> suspected.
>>>
>>>
>> https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
>>>
>>> There is a note here that says "The authorization plugin is only
>>> supported in SolrCloud mode. Also, reloading the plugin isn’t yet
>>> supported and requires a restart of the Solr installation (meaning,
>>> the JVM should be restarted, not simply a core reload)." The 6.6
>>> documentation contains the same note that you can see here in the
>>> latest docs.
>>>
>>> I have no idea how hard it would be to extend the authorization plugin
>>> to support standalone cores as well as collections. I imagine that if
>>> it were easy, it would have been done already.
>>>
>>> Thanks,
>>> Shawn
>>>
>>>
>>
Re: Continuing Saga of Authorization on 6.6.0
Posted by Chris Ulicny <cu...@iq.media>.
> *failed to delete a user:*
"delete-user" is expecting an array of users in the json, so the data
should be: {"delete-user": ["lanny"]}
> *failed to set a permission: *
There are separate endpoints for authorization and authentication. You
should use ".../solr/admin/authorization" for the permissions instead of
"../solr/admin/authentication"
https://lucene.apache.org/solr/guide/7_2/rule-based-authorization-plugin.html#manage-permissions
Disclaimer: I've never worked with 6.6, but I've not noticed any big
differences between the security for our 6.3 deployments and the 7.X ones.
Best,
Chris
On Tue, Mar 13, 2018 at 12:47 PM Terry Steichen <te...@net-frame.com> wrote:
> I switched solr from standalone to cloud and created the two collections
> (emails1 and emails2).
>
> I was able to create a basic set of credentials via the curl-based
> API's. I could create users, and toggle the blockUnknown property
> status. However, the system refused to allow me to delete a user, or to
> set a permission.
>
> Here are the curl commands (with *terry:admin* as admin credentials) and
> results:
>
> *succeeded in setting blockUnknown property (verified by
> admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{
> "set-property": {"blockUnknown" : true}}'
>
> *succeeded in adding a user (verified by admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{
> > "set-user": {"lanny" : "hawaii"}}'
>
> *succeeded in changing lanny's password (verified by
> admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{
> "set-user": {"lanny" : "hawaii_five_o"}}'
>
> *failed to delete a user:*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{
> "delete-user": {"lanny"}}'
> {
> "responseHeader":{
> "status":500,
> "QTime":1},
>
> "error":{ "msg":"Expected key,value separator ':': char=},position=26
> BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
> [terry here: plus a very long stack trace}
>
> *failed to set a permission: *
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{"set-permission" :
> {"name":"collection-admin-edit", "role":"admin"}}'
> {
> "responseHeader":{
> "status":0,
> "QTime":2},
> "errorMessages":[{
> "set-permission":{
> "name":"collection-admin-edit",
> "role":"admin"},
> "errorMessages":["Unknown operation 'set-permission' "]}]}
>
>
> This really makes no sense at all (or, I'm really losing it - always a
> distinct possibility). It's almost as if half of the documented
> parameters must have been changed, though I can't find any references to
> any such changes.
>
> I confess I'm about to just give up and find some other route to go.
>
> Terry
>
>
> On 03/12/2018 11:15 PM, Shawn Heisey wrote:
> > On 3/12/2018 8:39 PM, Terry Steichen wrote:
> >> I'm increasingly of the view that Solr's authentication/authorization
> >> mechanism doesn't work correctly in a _standalone_ mode. It was present
> >> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
> >> it was supposed to be available in standalone mode too. It seems to
> >> partly work (when using the built-in permissions), but does not seem to
> >> work with customized, core-specific permissions.
> >
> > I suspected based on your last message that the authorization feature
> > might only work correctly in SolrCloud. The entire authentication
> > feature was designed for SolrCloud. Version 6.5 brought the
> > security.json file to standalone mode. This was LONG after the
> > feature was introduced in 5.2 and had a LOT of bugs fixed in the three
> > 5.3.x releases.
> >
> > I just found the section in the documentation confirming what I
> > suspected.
> >
> >
> https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
> >
> >
> > There is a note here that says "The authorization plugin is only
> > supported in SolrCloud mode. Also, reloading the plugin isn’t yet
> > supported and requires a restart of the Solr installation (meaning,
> > the JVM should be restarted, not simply a core reload)." The 6.6
> > documentation contains the same note that you can see here in the
> > latest docs.
> >
> > I have no idea how hard it would be to extend the authorization plugin
> > to support standalone cores as well as collections. I imagine that if
> > it were easy, it would have been done already.
> >
> > Thanks,
> > Shawn
> >
> >
>
>
Re: Continuing Saga of Authorization on 6.6.0
Posted by spoonerk <jo...@gmail.com>.
I wish unsubscribe worked
On Mar 13, 2018 9:47 AM, "Terry Steichen" <te...@net-frame.com> wrote:
> I switched solr from standalone to cloud and created the two collections
> (emails1 and emails2).
>
> I was able to create a basic set of credentials via the curl-based
> API's. I could create users, and toggle the blockUnknown property
> status. However, the system refused to allow me to delete a user, or to
> set a permission.
>
> Here are the curl commands (with *terry:admin* as admin credentials) and
> results:
>
> *succeeded in setting blockUnknown property (verified by
> admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{
> "set-property": {"blockUnknown" : true}}'
>
> *succeeded in adding a user (verified by admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{
> > "set-user": {"lanny" : "hawaii"}}'
>
> *succeeded in changing lanny's password (verified by
> admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{
> "set-user": {"lanny" : "hawaii_five_o"}}'
>
> *failed to delete a user:*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{
> "delete-user": {"lanny"}}'
> {
> "responseHeader":{
> "status":500,
> "QTime":1},
>
> "error":{ "msg":"Expected key,value separator ':': char=},position=26
> BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
> [terry here: plus a very long stack trace}
>
> *failed to set a permission: *
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{"set-permission" :
> {"name":"collection-admin-edit", "role":"admin"}}'
> {
> "responseHeader":{
> "status":0,
> "QTime":2},
> "errorMessages":[{
> "set-permission":{
> "name":"collection-admin-edit",
> "role":"admin"},
> "errorMessages":["Unknown operation 'set-permission' "]}]}
>
>
> This really makes no sense at all (or, I'm really losing it - always a
> distinct possibility). It's almost as if half of the documented
> parameters must have been changed, though I can't find any references to
> any such changes.
>
> I confess I'm about to just give up and find some other route to go.
>
> Terry
>
>
> On 03/12/2018 11:15 PM, Shawn Heisey wrote:
> > On 3/12/2018 8:39 PM, Terry Steichen wrote:
> >> I'm increasingly of the view that Solr's authentication/authorization
> >> mechanism doesn't work correctly in a _standalone_ mode. It was present
> >> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
> >> it was supposed to be available in standalone mode too. It seems to
> >> partly work (when using the built-in permissions), but does not seem to
> >> work with customized, core-specific permissions.
> >
> > I suspected based on your last message that the authorization feature
> > might only work correctly in SolrCloud. The entire authentication
> > feature was designed for SolrCloud. Version 6.5 brought the
> > security.json file to standalone mode. This was LONG after the
> > feature was introduced in 5.2 and had a LOT of bugs fixed in the three
> > 5.3.x releases.
> >
> > I just found the section in the documentation confirming what I
> > suspected.
> >
> > https://lucene.apache.org/solr/guide/7_2/authentication-
> and-authorization-plugins.html#authorization
> >
> >
> > There is a note here that says "The authorization plugin is only
> > supported in SolrCloud mode. Also, reloading the plugin isn’t yet
> > supported and requires a restart of the Solr installation (meaning,
> > the JVM should be restarted, not simply a core reload)." The 6.6
> > documentation contains the same note that you can see here in the
> > latest docs.
> >
> > I have no idea how hard it would be to extend the authorization plugin
> > to support standalone cores as well as collections. I imagine that if
> > it were easy, it would have been done already.
> >
> > Thanks,
> > Shawn
> >
> >
>
>