Thanks for the reply. The two smallest rules 1) "name":"all-admin", "collection": null, "path":"/*" "role:"somerole"
2) all core handlers "name":"all-core-handlers", "path":"/*" "role":"somerole" do work after I reset my security.json. But another magic things happened. After I accidentally just set the rule as : "name":"admin-all" "role":"admin" It still works well and I even need permission to Admin UI. Perfect for me but why? I am a inexperience solr user and can't figure out it, but I want to know why it works? And another error happens as thread "replica recovery" describe. The RecoveryStrategy on main server attempt to recover replica again and again maybe last forever. Now I can see happy red cramming on my Admin Logging UI! -----邮件原件----- 发件人: solr-user-return-118135-mabaizhang=126....@lucene.apache.org [mailto:solr-user-return-118135-mabaizhang=126....@lucene.apache.org] 代表 Noble Paul 发送时间: 2015年11月20日 1:40 收件人: solr-user@lucene.apache.org 主题: Re: Security Problems What is the smallest possible security.json required currently to protect all possible paths (except those served by Jetty)? You would need 2 rules 1) "name":"all-admin", "collection": null, "path":"/*" "role:"somerole" 2) all core handlers "name":"all-core-handlers", "path":"/*" "role":"somerole" ideally we should have a simple permission name called "all" (which we don't have) so that one rule should be enough "name":"all", "role":"somerole" Open a ticket and we should fix it for 5.4.0 It should also include the admin paths as well On Thu, Nov 19, 2015 at 6:02 PM, Jan Høydahl <jan....@cominvent.com> wrote: > Would it not be less surprising if ALL requests to Solr required > authentication once an AuthenticationPlugin was enabled? > Then, if no AuthorizationPlugin was active, all authenticated users could do > anything. > But if AuthorizationPlugin was configured, you could only do what your role > allows you to? > > As it is now it is super easy to forget a path, say you protect > /select but not /browse and /query, or someone creates a collection with some > new endpoints and forgets to update security.json - then that endpoint would > be wide open! > > What is the smallest possible security.json required currently to protect all > possible paths (except those served by Jetty)? > > -- > Jan Høydahl, search solution architect Cominvent AS - > www.cominvent.com > >> 18. nov. 2015 kl. 20.31 skrev Upayavira <u...@odoko.co.uk>: >> >> I'm very happy for the admin UI to be served another way - i.e. not >> direct from Jetty, if that makes the task of securing it easier. >> >> Perhaps a request handler specifically for UI resources which would >> make it possible to secure it all in a more straight-forward way? >> >> Upayavira >> >> On Wed, Nov 18, 2015, at 01:54 PM, Noble Paul wrote: >>> As of now the admin-ui calls are not protected. The static calls are >>> served by jetty and it bypasses the authentication mechanism >>> completely. If the admin UI relies on some API call which is served >>> by Solr. >>> The other option is to revamp the framework to take care of admin UI >>> (static content) as well. This would be cleaner solution >>> >>> >>> On Wed, Nov 18, 2015 at 2:32 PM, Upayavira <u...@odoko.co.uk> wrote: >>>> Not sure I quite understand. >>>> >>>> You're saying that the cost for the UI is not large, but then >>>> suggesting we protect just one resource (/admin/security-check)? >>>> >>>> Why couldn't we create the permission called 'admin-ui' and protect >>>> everything under /admin/ui/ for example? Along with the root HTML >>>> link too. >>>> >>>> Upayavira >>>> >>>> On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: >>>>> The authentication plugin is not expensive if you are talking in >>>>> the context of admin UI. After all it is used not like 100s of >>>>> requests per second. >>>>> >>>>> The simplest solution would be >>>>> >>>>> provide a well known permission name called "admin-ui" >>>>> >>>>> ensure that every admin page load makes a call to some resource >>>>> say "/admin/security-check" >>>>> >>>>> Then we can just protect that . >>>>> >>>>> The only concern thatI have is the false sense of security it >>>>> would give to the user >>>>> >>>>> But, that is a different point altogether >>>>> >>>>> On Wed, Nov 11, 2015 at 1:52 AM, Upayavira <u...@odoko.co.uk> wrote: >>>>>> Is the authentication plugin that expensive? >>>>>> >>>>>> I can help by minifying the UI down to a smaller number of >>>>>> CSS/JS/etc files :-) >>>>>> >>>>>> It may be overkill, but it would also give better experience. And >>>>>> isn't that what most applications do? Check authentication tokens >>>>>> on every request? >>>>>> >>>>>> Upayavira >>>>>> >>>>>> On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: >>>>>>> The reason why we bypass that is so that we don't hit the >>>>>>> authentication plugin for every request that comes in for static >>>>>>> content. I think we could call the authentication plugin for >>>>>>> that but that'd be an overkill. Better experience ? yes >>>>>>> >>>>>>> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira <u...@odoko.co.uk> wrote: >>>>>>> >>>>>>>> Noble, >>>>>>>> >>>>>>>> I get that a UI which is open source does not benefit from ACL >>>>>>>> control - we're not giving away anything that isn't public >>>>>>>> (other than perhaps info that could be used to identify the >>>>>>>> version of Solr, or even the fact that it *is* solr). >>>>>>>> >>>>>>>> However, from a user experience point of view, requiring >>>>>>>> credentials to see the UI would be more conventional, and >>>>>>>> therefore lead to less confusion. Is it possible for us to >>>>>>>> protect the UI static files, only for the sake of user experience, >>>>>>>> rather than security? >>>>>>>> >>>>>>>> Upayavira >>>>>>>> >>>>>>>> On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: >>>>>>>>> The admin UI is a bunch of static pages . We don't let the ACL >>>>>>>>> control static content >>>>>>>>> >>>>>>>>> you must blacklist all the core/collection apis and it is >>>>>>>>> pretty much useless for anyone to access the admin UI (w/o the >>>>>>>>> credentials , of >>>>>>>>> course) >>>>>>>>> >>>>>>>>> On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 <mabaizh...@126.com> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> After I configure Authentication with Basic Authentication >>>>>>>>>> Plugin and >>>>>>>> Authorization with Rule-Based Authorization Plugin, How can I >>>>>>>> prevent the strangers from visiting my solr by browser? For >>>>>>>> example, if the stranger visit the http://(my host):8983, the >>>>>>>> browser will pop up a window and says "the server http://(my >>>>>>>> host):8983 requires a username and password...." >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ----------------------------------------------------- >>>>>>>>> Noble Paul >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Anshum Gupta >>>>> >>>>> >>>>> >>>>> -- >>>>> ----------------------------------------------------- >>>>> Noble Paul >>> >>> >>> >>> -- >>> ----------------------------------------------------- >>> Noble Paul > -- ----------------------------------------------------- Noble Paul
