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}}}
>

Reply via email to