Re: alias read access impossible for anyone other than admin?
Hi Json, Many thanks for this excellent explanation, it's all now clear to me, I've fixed the problem! I didn't anticipate that the aliases would be resolved before everything else.. Thanks again! Sotiri On Tue, Jun 4, 2019 at 2:07 PM Jason Gerlowski wrote: > Hi Sotiris, > > First off, forget what I said earlier about the "all" permission. > What I said is mostly correct, but I had forgotten about some of the > other behavior here that complicates things some. > > I replicated the behavior you're seeing and spent a bit of time > tracing things through on the Solr side. I'll walk through it below > in more detail, but ultimately what I think you're running into is > that aliases are resolved _before_ authorization is done. The only > way to write permissions affecting an alias is to write permissions > that affect the underlying collections. The way I'm reading the authz > code, a permission like {"collection": "sCollAlias", "path": > "/select/*", "role": "readSCollAlias"} (taken from your first email), > will never have any effect because Solr treats that incoming request > as being for collection "sColl" (I'm just guessing at this name) by > the point authz gets triggered. > > > Could someone please ELI5 going through the rules one by one? > > RBAP's process of authorizing requests is complicated, but it might > help to think of it happening in 2 distinct steps: > > 1. Find the first rule (if any) that matches the incoming request. A > rule matches if the "collection", "path", "method", and "params" > properties all match values in the incoming request. > 2. Looks at the "role" for the selected permission. Allow the request > if the user making the request has this role. Otherwise deny the > request. > > The second half of this process is pretty straightforward. The first > half (determining which permission rule governs the request) is the > complicated bit that causes most of the confusion. So in debugging > RBAP, the real question is: how are permissions ordered, and how does > Solr determine which one matches an incoming request? > > 1. First, Solr figures out which collections are involved in a > request. Solr looks at the path param (e.g. /solr/foo/select), the > "collection" query-param (e.g. > /collections?action=CLUSTERSTATUS=foo), and resolves any > aliases (e.g. fooAlias -> fooCollection). It gets the collections > referenced in all these places and puts them together in a list. > 2. Solr begins looking for rules that match the incoming request. A > permission is considered a match if the "collection", "path", > "method", and "params" properties (when defined) all match values on > the incoming request. security.json shows the permissions in a flat > list, but this isn't the order they're tested in. Instead, the > permissions are tested in the following order: > 2a. Permissions with both "collection" and "path" present and matching > the incoming request > 2b. Permissions with "collection" matching, but no path specified > 2c. Permissions with no "collection" specified (or the wildcard values > specified) and a "path" matching the incoming request > 2d. Permissions agnostic of both "collection" and "path" > 3. Within each of the sub-steps above, permissions are tested in the > order they appear in security.json. > 4. When testing each individual permission, Solr either looks at the > remaining properties ("method", "params"). If those check out, we've > got a winner. This is the only permission that will matter for this > request. > > So that's the logic in how the rules are processed. Let's walk > through your originally posted security.json and see how this works > out in practice for a request from "user". I'm assuming that > sCollAlias is an alias that references the single collection "Coll". > Imagine a request from "user" for > http://:8983/solr/sCollAlias/select?q=*:* > > 1. Solr looks at the request and realizes that sCollAlias really > points to Coll. It puts "Coll" in its list of referenced-collections. > 2. Solr looks for permissions with a "collection" value of "Coll" and > a path value of "/select". There is one: {name:readColl, > collection:Coll, path:/select, role:readColl} > 3. Looking at that permission further, Solr makes sure the "method" > and "params" properties match the request. Since the properties > aren't present, they're treated as wildcards and implicitly match. > 4. So we've found a matching permission, now Solr checks whether > "user" has the correct role. The permission says that this request > can only be made by those with the role "readColl". But "user" only > has the role "readSCollAlias". So the request is denied. > > Hope that example helps. Let me know if you have any more questions. > > Best, > > Jason > > On Mon, Jun 3, 2019 at 2:06 PM Sotiris Fragkiskos > wrote: > > > > it's 7.2.1. Thanks! > > > > On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski > > wrote: > > > > > Hi Sotiris, > > > > > > What version of Solr are you
Re: alias read access impossible for anyone other than admin?
Hi Sotiris, First off, forget what I said earlier about the "all" permission. What I said is mostly correct, but I had forgotten about some of the other behavior here that complicates things some. I replicated the behavior you're seeing and spent a bit of time tracing things through on the Solr side. I'll walk through it below in more detail, but ultimately what I think you're running into is that aliases are resolved _before_ authorization is done. The only way to write permissions affecting an alias is to write permissions that affect the underlying collections. The way I'm reading the authz code, a permission like {"collection": "sCollAlias", "path": "/select/*", "role": "readSCollAlias"} (taken from your first email), will never have any effect because Solr treats that incoming request as being for collection "sColl" (I'm just guessing at this name) by the point authz gets triggered. > Could someone please ELI5 going through the rules one by one? RBAP's process of authorizing requests is complicated, but it might help to think of it happening in 2 distinct steps: 1. Find the first rule (if any) that matches the incoming request. A rule matches if the "collection", "path", "method", and "params" properties all match values in the incoming request. 2. Looks at the "role" for the selected permission. Allow the request if the user making the request has this role. Otherwise deny the request. The second half of this process is pretty straightforward. The first half (determining which permission rule governs the request) is the complicated bit that causes most of the confusion. So in debugging RBAP, the real question is: how are permissions ordered, and how does Solr determine which one matches an incoming request? 1. First, Solr figures out which collections are involved in a request. Solr looks at the path param (e.g. /solr/foo/select), the "collection" query-param (e.g. /collections?action=CLUSTERSTATUS=foo), and resolves any aliases (e.g. fooAlias -> fooCollection). It gets the collections referenced in all these places and puts them together in a list. 2. Solr begins looking for rules that match the incoming request. A permission is considered a match if the "collection", "path", "method", and "params" properties (when defined) all match values on the incoming request. security.json shows the permissions in a flat list, but this isn't the order they're tested in. Instead, the permissions are tested in the following order: 2a. Permissions with both "collection" and "path" present and matching the incoming request 2b. Permissions with "collection" matching, but no path specified 2c. Permissions with no "collection" specified (or the wildcard values specified) and a "path" matching the incoming request 2d. Permissions agnostic of both "collection" and "path" 3. Within each of the sub-steps above, permissions are tested in the order they appear in security.json. 4. When testing each individual permission, Solr either looks at the remaining properties ("method", "params"). If those check out, we've got a winner. This is the only permission that will matter for this request. So that's the logic in how the rules are processed. Let's walk through your originally posted security.json and see how this works out in practice for a request from "user". I'm assuming that sCollAlias is an alias that references the single collection "Coll". Imagine a request from "user" for http://:8983/solr/sCollAlias/select?q=*:* 1. Solr looks at the request and realizes that sCollAlias really points to Coll. It puts "Coll" in its list of referenced-collections. 2. Solr looks for permissions with a "collection" value of "Coll" and a path value of "/select". There is one: {name:readColl, collection:Coll, path:/select, role:readColl} 3. Looking at that permission further, Solr makes sure the "method" and "params" properties match the request. Since the properties aren't present, they're treated as wildcards and implicitly match. 4. So we've found a matching permission, now Solr checks whether "user" has the correct role. The permission says that this request can only be made by those with the role "readColl". But "user" only has the role "readSCollAlias". So the request is denied. Hope that example helps. Let me know if you have any more questions. Best, Jason On Mon, Jun 3, 2019 at 2:06 PM Sotiris Fragkiskos wrote: > > it's 7.2.1. Thanks! > > On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski > wrote: > > > Hi Sotiris, > > > > What version of Solr are you running? The behavior has changed some > > over time, both intentionally and due to bugs that have come and gone > > over time. I (or someone else) can explain things and offer you > > better help once we know your Solr version. > > > > Jason > > > > On Mon, Jun 3, 2019 at 12:13 PM Sotiris Fragkiskos > > wrote: > > > > > > Hi again, > > > > > > I moved the "all" permission to the bottom as suggested, but it still > > > doesn't work. Actually, i
Re: alias read access impossible for anyone other than admin?
it's 7.2.1. Thanks! On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski wrote: > Hi Sotiris, > > What version of Solr are you running? The behavior has changed some > over time, both intentionally and due to bugs that have come and gone > over time. I (or someone else) can explain things and offer you > better help once we know your Solr version. > > Jason > > On Mon, Jun 3, 2019 at 12:13 PM Sotiris Fragkiskos > wrote: > > > > 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://@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 > > 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 > > > > 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",
Re: alias read access impossible for anyone other than admin?
Hi Sotiris, What version of Solr are you running? The behavior has changed some over time, both intentionally and due to bugs that have come and gone over time. I (or someone else) can explain things and offer you better help once we know your Solr version. Jason On Mon, Jun 3, 2019 at 12:13 PM Sotiris Fragkiskos wrote: > > 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://@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 > 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 > > 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
Re: alias read access impossible for anyone other than admin?
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://@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 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 > 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 >> 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: >> >
Re: alias read access impossible for anyone other than admin?
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 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 > 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://:@/solr > > //select?q=: > > 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}}} >
Re: alias read access impossible for anyone other than admin?
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 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://:@/solr > //select?q=: > 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}}}
alias read access impossible for anyone other than admin?
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://:@/solr //select?q=: 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}}}
Re: alias read access impossible for anyone other than admin?
Thanks Jason. We are awaiting the 7.7.2 release. I will send out a note describing how the documentation is easy to mess-up. Maybe this is worth writing a blog for folks like yourselves who are experts in this :) > On May 28, 2019, at 4:31 AM, Jason Gerlowski wrote: > > Hey Aroop, > > The fix in SOLR-13355 is available starting in 8.1. It will also be > available in 7.7.2 once that is released. (Jan Hoydahl started the > release process for 7.7.2, but held off for a number of other ongoing > releases. He's recently resumed work on the release though, and I > expect we'll see 7.7.2 in a week or two.) > > RuleBasedAuthorizationPlugin does have some coverage in the ref-guide, > as you've likely seen: > https://lucene.apache.org/solr/guide/7_7/rule-based-authorization-plugin.html. > I don't think SOLR-13355 involved any changes to that documentation: > it fixed a bug that deviated from what was described in the ref-guide, > so there were no changes required when that bug was fixed. That said, > if you see something I've missed, or think that page could be improved > more generally, it's definitely worth raising a JIRA for. RBAP > permission matching/processing can be subtle for those using it for > the first time, so any improvement to the docs will go a long way. > > Jason > > On Sat, May 25, 2019 at 3:12 AM Aroop Ganguly wrote: >> >> hi jason >> >> which version of solr has the definitive fix for the rbap again ? >> also is there a jira to fix or create a documentation for the same that >> works :) ? >> >> aroop >> >> >>> On May 24, 2019, at 9:55 AM, Jason Gerlowski wrote: >>> >>> 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. >>> >>> Jason >>> >>> On Wed, May 22, 2019 at 6:21 AM Sotiris Fragkiskos >>> 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:// :@/solr//select?q=: 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}}} >>
Re: alias read access impossible for anyone other than admin?
Hey Aroop, The fix in SOLR-13355 is available starting in 8.1. It will also be available in 7.7.2 once that is released. (Jan Hoydahl started the release process for 7.7.2, but held off for a number of other ongoing releases. He's recently resumed work on the release though, and I expect we'll see 7.7.2 in a week or two.) RuleBasedAuthorizationPlugin does have some coverage in the ref-guide, as you've likely seen: https://lucene.apache.org/solr/guide/7_7/rule-based-authorization-plugin.html. I don't think SOLR-13355 involved any changes to that documentation: it fixed a bug that deviated from what was described in the ref-guide, so there were no changes required when that bug was fixed. That said, if you see something I've missed, or think that page could be improved more generally, it's definitely worth raising a JIRA for. RBAP permission matching/processing can be subtle for those using it for the first time, so any improvement to the docs will go a long way. Jason On Sat, May 25, 2019 at 3:12 AM Aroop Ganguly wrote: > > hi jason > > which version of solr has the definitive fix for the rbap again ? > also is there a jira to fix or create a documentation for the same that works > :) ? > > aroop > > > > On May 24, 2019, at 9:55 AM, Jason Gerlowski wrote: > > > > 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. > > > > Jason > > > > On Wed, May 22, 2019 at 6:21 AM Sotiris Fragkiskos > > 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:// > >> :@/solr//select?q=: > >> 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}}} >
Re: alias read access impossible for anyone other than admin?
hi jason which version of solr has the definitive fix for the rbap again ? also is there a jira to fix or create a documentation for the same that works :) ? aroop > On May 24, 2019, at 9:55 AM, Jason Gerlowski wrote: > > 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. > > Jason > > On Wed, May 22, 2019 at 6:21 AM Sotiris Fragkiskos 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:// >> :@/solr//select?q=: >> 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}}}
Re: alias read access impossible for anyone other than admin?
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. Jason On Wed, May 22, 2019 at 6:21 AM Sotiris Fragkiskos 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:// > :@/solr//select?q=: > 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}}}
alias read access impossible for anyone other than admin?
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:// :@/solr//select?q=: 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}}}