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 [email protected] or file a JIRA ticket
with INFRA.
---
