Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: geomacy <git@git.apache.org>
To: dev@brooklyn.apache.org
Reply-To: dev@brooklyn.apache.org
References: <git-pr-519-brooklyn-server@git.apache.org>
In-Reply-To: <git-pr-519-brooklyn-server@git.apache.org>
Subject: [GitHub] brooklyn-server pull request #519: Add experimental CORS server support
Content-Type: text/plain
Message-Id: <20170118105040.7F6A3DFA70@git1-us-west.apache.org>
Date: Wed, 18 Jan 2017 10:50:40 +0000 (UTC)
archived-at: Wed, 18 Jan 2017 10:50:42 -0000

Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/519#discussion_r96608309
  
    --- Diff: rest/rest-resources/src/main/java/org/apache/brooklyn/rest/filter/CorsImplSupplierFilter.java ---
    @@ -0,0 +1,99 @@
    +/*
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *     http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing,
    + * software distributed under the License is distributed on an
    + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    + * KIND, either express or implied.  See the License for the
    + * specific language governing permissions and limitations
    + * under the License.
    + */
    +package org.apache.brooklyn.rest.filter;
    +
    +import com.google.common.reflect.TypeToken;
    +import org.apache.brooklyn.api.mgmt.ManagementContext;
    +import org.apache.brooklyn.config.ConfigKey;
    +import org.apache.brooklyn.core.BrooklynFeatureEnablement;
    +import org.apache.brooklyn.core.config.ConfigKeys;
    +import org.apache.brooklyn.util.JavaGroovyEquivalents;
    +import org.apache.cxf.rs.security.cors.CrossOriginResourceSharingFilter;
    +import org.slf4j.Logger;
    +import org.slf4j.LoggerFactory;
    +
    +import javax.annotation.Nullable;
    +import javax.ws.rs.container.ContainerRequestContext;
    +import javax.ws.rs.container.ContainerResponseContext;
    +import javax.ws.rs.ext.Provider;
    +import java.util.Collections;
    +import java.util.List;
    +
    +/**
    + * We strongly discourage enabling CORS!
    + * Using CORS expose you at great security risk!
    + * If you are thinking about using CORS on Apache Brooklyn side then probably that's the wrong solution to your problem.
    + * We recommend using middleware for delegating API requests from third party web applications.
    + * Apache Brooklyn API requests should be exposed to third party web apps with great attention and complete testing.
    + * The right fix is to change your calling structure; architecturally, the browser shouldn't be calling the Apache Brooklyn APIs directly.
    + * A web app should be interacting solely with the Apache Brooklyn server.
    + * If there is a need to get information from Apache Brooklyn APIs then,
    + * it could either simply proxy the request or could do the request on the client's behalf and potentially further processing on the results before finally getting back to the client.
    + *
    + * If brooklyn.experimental.feature.corsCxfFeature.allowedOrigins is not supplied then allowedOrigins will be on all domains.
    + *
    + * Currently there is no fine per API request control it is rather applied to the entire server.
    + * Even if you have per API request control and apply CORS to groups of pages/resources,
    + * then you have to think about how to configure the values that get added to the CORS header,
    + * as you really don't want to use a "*" wildcard.
    + * Also you have to think about what the user interface is to capture this config, and maybe issues around how to persist it, upgrade etc.
    + *
    + * It is best when web app communicates just with its own server, not with multiple servers.
    + * It's the Apache Brooklyn server that should be the single point of contact to moderate and control access to the information from the AMP API, which should never be independently exposed to a web UI.
    + * This sort of architecture can give you additional headaches behind proxies, with firewalls, etc.
    + * For another thing, CORS can be used and can be secure enough up to a point if implemented right (and that's not a trivial 'if'),
    + * but it is still an additional attack vector that can be exploited by mitm attacks etc.
    + * In short, the proposed architecture and use of CORS is more complex, less secure,
    + * and more difficult to manage than the alternative of web client ---> Apache Brooklyn Server ----> fan out to backend servers + Apache Brooklyn API + etc.
    + *
    + * Notes by Geoff Macartney.
    + */
    +@Provider
    +public class CorsImplSupplierFilter extends CrossOriginResourceSharingFilter {
    +    public static final ConfigKey<List<String>> ALLOWED_ORIGINS = ConfigKeys.newConfigKey(new TypeToken<List<String>>() {}, BrooklynFeatureEnablement.FEATURE_CORS_CXF_PROPERTY + ".allowedOrigins");
    --- End diff --
    
    I don't think the config will be hundreds of lines as it is only the domain of the requesting site that needs to be added to the header, not separate entries for each page that may do the request.  There will only be a handful of domains in most use-cases, I expect.
    
    @neykov for the configuration, I agree up to a point; we probably need to think a bit about recommendations for what sort of configs are most appropriate in brooklyn.cfg, and what are better done in the conventional Karaf way of having a PID for a feature, e.g. for CORS you would have a cfg file such as `org.apache.brooklyn.rest.filter.cors.cfg` with the appropriate config in it.  However, as there is only one property to be configured, I think that is probably overkill for this scenario.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---