Hi again,
I moved the "all" permission to the bottom as suggested, but it still
doesn't work. Actually, i tried all possible combinations that I could
think of, but I just can't get it to work.
Could there be something else that I'm doing wrong? I'm a complete newbie,
so pretty much anything is a possibility at this point :(
Could it be because I use getfile/putfile commands to update the
security.json file? (it seems to be working, i.e. what i put with putfile
is later retrieved successfully with getfile)
Could there be some system update/refresh mechanism that I'm not aware of
and is currently not taking place?
Could someone please ELI5 going through the rules one by one? I can't
exactly understand the "narrative" that's going on,
My security.json file's "authorization" at this point looks like the
snippet below, and almost nothing is working (except admin, and userC who,
for some weird reason, can access readCollC55b , which is tied to a role
that the userC is NOT tied to..
I'm completely lost.... any pointers, anyone?
Mind you, i'm testing whether it works either directly in the browser by
prepending a "username:password@" to the URL or from the cmdline with a
curl command like so:
*curl http://<user:pass>@IP/solr/collName/select?q=field:value*
Many thanks!
Sotiri
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"permissions":[
{
"name":"readCollA",
"collection":"CollA",
"path":"/select/*",
"role":"readCollA",
"index":1},
{
"name":"readCollB",
"collection":"CollB",
"path":"/select/*",
"role":"readCollB",
"index":2},
{
"name":"readCollC55b",
"collection":"CollC55b",
"path":"/select/*",
"role":"readCollC55b",
"index":3},
{
"name":"readCollCProduction",
"collection":"CollCProd",
"path":"/select/*",
"role":"readCollCProduction",
"index":4},
{
"name":"all",
"role":"admin",
"index":5}],
"user-role":{
"admin":[
"admin",
"readCollB",
"readCollA",
"readCollC55b",
"readCollCProduction"],
"userA":["readCollC55b"],
"userB":["readCollC55b"],
"userC":["readCollCProduction"],
"userD":[
"readCollCProduction",
"readCollC55b",
"readCollB",
"readCollA"]},
On Fri, May 31, 2019 at 9:07 PM Sotiris Fragkiskos <sfra...@gmail.com>
wrote:
> Terribly sorry about the duplicate post. It was just when i had first
> subscribed, i mustn't have verified my subscription because i never
> received any posts. I could also not find my post in the mailing list
> archive, so I thought it never arrived. It was only today that I tried
> subscribing again (+verifying) that I started receiving emails.
> Thanks for your explanation, I had read this in the manual but it didn't
> make much sense to me. I intepreted my order as: "first rule, the request
> is not from an admin so fail, check the next rule, it's from role readColl
> trying to access Coll, go ahead"
> I will try it as soon as I can. Thanks very much.
> I'm currently using 7.2.
>
> On Fri, May 31, 2019 at 8:27 PM Jason Gerlowski <gerlowsk...@gmail.com>
> wrote:
>
>> Hi Sotiris,
>>
>> Is this your second time asking this question here, or is there a
>> subtle difference I'm missing? You asked a very similar question a
>> week or so ago, and I replied with a few suggestions for changing your
>> security.json and with a few questions. In case you missed it for
>> whatever reason, I'll include my original response below:
>>
>> -----
>>
>> Hi Sotiris,
>>
>> First, what version of Solr are you running? We've made some fixes
>> recently (esp. SOLR-13355) to RBAP, and they might affect the behavior
>> you're seeing or any fixes we can recommend.
>>
>> Second, the order of permissions in security.json has a huge effect on
>> how . Solr always uses the first permission rule that matches a given
>> API...later rules are ignored if a match is found in earlier ones.
>> The first rule in your permissions block ({"name": "all", "role":
>> "admin"}) will match all APIs and will only allow requests through if
>> the requesting user has the "admin" role. So "user" being unable to
>> query an alias makes sense. Usually "all" and other catchall
>> permissions are best used at the very bottom of your permissions list.
>> That way the catchall is the last rule to be checked, giving other
>> rules a chance to match first.
>>
>> Hope that helps.
>>
>> On Fri, May 31, 2019 at 9:34 AM Sotiris Fragkiskos <sfra...@gmail.com>
>> wrote:
>> >
>> > Hi everyone!
>> > I've been trying unsuccessfully to read an alias to a collection with a
>> > curl command.
>> > The command only works when I put in the admin credentials, although the
>> > user I want access for also has the required role for accessing.
>> > Is this perhaps built-in, or should anyone be able to access an alias
>> from
>> > the API?
>> >
>> > The command I'm using is:
>> > curl http://<user>:<pass>@<solrhostname>/solr
>> > /<AliasName>/select?q=<field>:<value>
>> > This fails for the user but succeeds for the admin
>> >
>> > My minimum working example of security.json follows.
>> > Many thanks!
>> >
>> > {
>> > "authentication":{
>> > "blockUnknown":true,
>> > "class":"solr.BasicAuthPlugin",
>> > "credentials":{
>> > "admin":"blahblahblah",
>> > "user":"blahblah"},
>> > "":{"v":13}},
>> > "authorization":{
>> > "class":"solr.RuleBasedAuthorizationPlugin",
>> > "permissions":[
>> > {
>> > "name":"all",
>> > "role":"admin",
>> > "index":1},
>> > {
>> > "name":"readColl",
>> > "collection":"Coll",
>> > "path":"/select/*",
>> > "role":"readColl",
>> > "index":2},
>> > {
>> > "name":"readSCollAlias",
>> > "collection":"sCollAlias",
>> > "path":"/select/*",
>> > "role":"readSCollAlias",
>> > "index":3}],
>> > "user-role":{
>> > "admin":[
>> > "admin",
>> > "readSCollAlias"],
>> > "user":["readSCollAlias"]},
>> > "":{"v":21}}}
>>
>
