brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From geomacy <>
Subject [GitHub] brooklyn-server pull request #519: Add experimental CORS server support
Date Wed, 18 Jan 2017 10:50:40 GMT
Github user geomacy commented on a diff in the pull request:
    --- Diff: rest/rest-resources/src/main/java/org/apache/brooklyn/rest/filter/
    @@ -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
    + *
    + *
    + *
    + * Unless required by applicable law or agreed to in writing,
    + * software distributed under the License is distributed on an
    + * KIND, either express or implied.  See the License for the
    + * specific language governing permissions and limitations
    + * under the License.
    + */
    +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.slf4j.Logger;
    +import org.slf4j.LoggerFactory;
    +import javax.annotation.Nullable;
    +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
    + * 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
    + * 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,
    + * 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
    + * 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.
    + */
    +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 `` 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 or file a JIRA ticket
with INFRA.

View raw message