Github user geomacy commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/519#discussion_r96459739
--- Diff:
core/src/main/java/org/apache/brooklyn/core/BrooklynFeatureEnablement.java ---
@@ -61,6 +61,37 @@
/** whether feeds are automatically registered when set on entities,
so that they are persisted */
public static final String FEATURE_FEED_REGISTRATION_PROPERTY =
FEATURE_PROPERTY_PREFIX+".feedRegistration";
+ /**
+ * 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.
--- End diff --
Definitely don't blame me! :-)
---
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.
---
