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

Reply via email to