Hi Am 09.10.2013 um 09:05 schrieb Ian Boston:
> Hi,
>
> On 9 October 2013 16:21, Felix Meschberger <fmesc...@adobe.com> wrote:
>> Hi
>>
>> Am 08.10.2013 um 10:40 schrieb Ian Boston:
>>
>>> Hi,
>>> The whitelist configuration in this servlet is causing some problems
>>> where the contents of the whitelist is potentially large and changing,
>>> since it requires constant re-configuration.
>>
>> What is the problem with that ?
>
> When the whitelist in the central discovery endpoint depends on the
> topology itself, it causes production deployment problems, especially
> when the configuration of the end point and the management of the
> topology of the production deployment are managed by different roles
> within the organisation. This is typical of many organisations.
> Engineers don't manage operations and TechOps don't manage
> engineering. Normally configuration would be managed by TechOps but
Fully agreed ! Which is exactly the reason why conceptually we have to separate
development from deployment and which is why configuration *is* in fact a
deployment issue and not a development issue.
> with Sling that doesn't appear to be the case.
How come ? That is not the intent of how Sling should be used.
> Consequently the 2 get
> out of sync, and if you are using Sling Discovery to transport
> metadata about your topology, lots of things start to break when nodes
> are not in the whitelist.
Sure, if developers want to be involved with deployment, things run havock.
>
> In our special case we have 1 central discovery end point, if we had
> n, the problem would multiply by n.
>
>>
>> And why would a service API help mitigate that issue ?
>
> It would give those that are able to see the deployment infrastructure
> that they are dealing with, the opportunity to address this issue.
>
>> Considering that service would have to be reconfigured, too, and your code
>> sample belows uses a static reference ?
>
> AFAIK it uses an optional reference, satisfied by a implementation
> outside Sling. The snippet was written from memory directly into the
> email to communicate what I was trying to discuss. Its is not real
> code.
>
>>
>> Also, noted in another thread, this would require export of the API from the
>> impl bundle, which I am not very happy with...
>>
>> Finally -- and this is purely subjective -- I am not very happy with the
>> name WhiteListProvider and then WhiteListProvider.isWhiteListed... Also
>> would there be other needs for hooking into this servlet ?
>>
>
> I have been working on an implementation most of the day that is
> nothing like what was first discussed, I will commit in a moment. Much
> better to share real code with unit test coverage.
Ok.
Regards
Felix
>
> Best Regards
> Ian
>
>
>> Regards
>> Felix
>>
>>
>>
>>>
>>> Would it be possible to have a API service that is consulted if
>>> present to check if the request is allowed. For those that want to use
>>> the service they would configure the whitelist to reject everything
>>> while the service was not present so avoid startup issues.
>>>
>>> eg
>>>
>>> + @Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
>>> + private WhiteListProvider whiteListProvider;
>>>
>>> /** Checks if the provided request's remote server is whitelisted **/
>>>
>>> private boolean isWhitelisted(final SlingHttpServletRequest request) {
>>> + if (whiteListProvider != null) {
>>> + whiteListProvider.isWhitelisted(request);
>>> + }
>>> if (whitelist.contains(request.getRemoteAddr())) {
>>>
>>> return true;
>>>
>>> } else if (whitelist.contains(request.getRemoteHost())) {
>>>
>>> return true;
>>>
>>> }
>>>
>>> logger.info("isWhitelisted: rejecting " + request.getRemoteAddr()
>>>
>>> + ", " + request.getRemoteHost());
>>>
>>> return false;
>>>
>>> }
>>>
>>>
>>> and in the API, presumably discovery api.
>>>
>>> public interface WhiteListProvider {
>>>
>>> private boolean isWhitelisted(HttpServletRequest request);
>>>
>>> }
>>>
>>>
>>> Best Regards
>>> Ian
>>
smime.p7s
Description: S/MIME cryptographic signature
