brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From geomacy <...@git.apache.org>
Subject [GitHub] brooklyn-server pull request #519: Add experimental CORS server support
Date Tue, 17 Jan 2017 17:42:35 GMT
Github user geomacy commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/519#discussion_r96460561
  
    --- 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");
    +    private static final Logger LOGGER = LoggerFactory.getLogger(CorsImplSupplierFilter.class);
    +
    +    private static final boolean brooklynFeatureEnabled = BrooklynFeatureEnablement.isEnabled(BrooklynFeatureEnablement.FEATURE_CORS_CXF_PROPERTY);
    +    static {
    +        if (brooklynFeatureEnabled) {
    +            LOGGER.warn("CORS brooklyn feature enabled.");
    --- End diff --
    
    info not warn


---
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.
---

Mime
View raw message