[rhq-metrics] False positives on Javascript license checks
by mike thompson
These *.js and *.map files should not be checked for license (think of them as compiled binary output and not checked in). All of our projects are typescript (*.ts) projects which is where the license checking should occur. The *.js and *.map files are compiled output from the typescript compiler. The .map files are debugging files (sourcemaps) used by the browser to allow debugging in the source language such as typescript.
So the license checker should look at *.ts files and look for /// comments that typescript doesn’t compile to js. Tsegismont went through and added the license headers in a while back.
[INFO] --- license-maven-plugin:2.7:check (default) @ explorer ---
[INFO] Checking licenses...
[WARNING] Unknown file extension: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/app.js.map
[WARNING] Unknown file extension: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/controllers/chart-controller.js.map
[WARNING] Unknown file extension: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/controllers/config-controller.js.map
[WARNING] Unknown file extension: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/controllers/insert-metrics-controller.js.map
[WARNING] Unknown file extension: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/controllers/metric-overlay-controller.js.map
[WARNING] Unknown file extension: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/directives/date-time-range-selection-directive.js.map
[WARNING] Unknown file extension: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/directives/enter-key-directive.js.map
[WARNING] Unknown file extension: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/services/metric-data-service.js.map
[WARNING] Missing header in: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/controllers/insert-metrics-controller.js
[WARNING] Missing header in: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/controllers/config-controller.js
[WARNING] Missing header in: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/controllers/chart-controller.js
[WARNING] Missing header in: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/app.js
[WARNING] Missing header in: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/directives/enter-key-directive.js
[WARNING] Missing header in: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/controllers/metric-overlay-controller.js
[WARNING] Missing header in: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/services/metric-data-service.js
[WARNING] Missing header in: /Users/mtho11/projects/rhq-metrics/ui/explorer/src/main/webapp/scripts/directives/date-time-range-selection-directive.js
9 years, 2 months
Keycloak integration
by Juraci Paixão Kröhling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
All,
I finally got some time to work a bit more on the Keycloak integration.
== TL;DR:
I'd like to get a review/comments/suggestions for the following:
Branch:
https://github.com/jpkrohling/rhq-metrics/tree/JPK-KCAuthentication-Draft
Comparison:
https://github.com/jpkrohling/rhq-metrics/compare/rhq-project:master...jp...
== Long version
A few words about Keycloak:
- - Keycloak has an authentication server, and can be deployed as a WAR
file.
- - Keycloak has also adapters, to make it easy for applications to
authenticate against an auth server. Basically, an application (WAR,
like rhq-metrics) just define the auth method as "KEYCLOAK" and the
adapter takes care of loading the configuration from keycloak.json and
intercepting all the requests to authenticate/authorize it, exposing
the principal as a regular JAAS subject. For metrics-console, there's
a javascript adapter.
- - To make it easier to get an auth server with adapters, they also
provide an "appliance" version, which includes all the bits. This is
currently based on WildFly 8.1.0.Final and will be using 8.2.0.Final
for the next release.
This effectively means that Keycloak Auth Server can be running on one
node and rhq-metrics in another. But I assume that for development,
the appliance is the easiest solution.
Keycloak has also a notion of "realms", which we are using on a
per-tenant basis: each tenant is a realm in Keycloak. In the
integration code, I'm using two realms to demonstrate the
multi-tenancy capability: "acme-roadrunner-affairs" and
"acme-other-affairs". Each represents a department inside Acme, Inc.
We can define realms as JSON files, and import them during the first
boot, which is convenient for a "getting started" scenario. The JSON
file can also be imported via the Auth Server Web UI, if
needed/required/wanted.
Inside a realm, we define applications, roles and users. By
applications, I mean "metrics-console" and "rhq-metrics", for
instance. By roles, we currently have "admin", "user" and "agent",
which were the ones I imagined as the first roles to add. By users, we
have only one standard user: "agent" (which has an "agent" role). Each
additional user self-registers during the first login.
This all means that we now have two options:
- - use the start.sh to generate random keys and certificates, so that
we don't have "default" ones (it's like having default passwords, and
I think we know how bad it is)
- - use the start.sh only for minimal stuff (copying things around and
starting Keycloak). This implies that we'd have default
passwords/secrets/keys.
I've tried to keep the start.sh as simple as possible, and most of the
things there are replacing tokens and copying things around, but I
know that this wouldn't be easy to maintain for someone who is looking
at it for the first time.
Pretty much nothing else is intrusive, but I'd appreciate feedback
there as well.
And a final note: on the metrics-console, the JavaScript code there is
as real JavaScript. I intend to re-write as TypeScript, as it seems
that's the chosen language. I'd need some time to study TypeScript,
though :-)
So, all that said, I'd like to share the following changes for
review/discussion:
Branch:
https://github.com/jpkrohling/rhq-metrics/tree/JPK-KCAuthentication-Draft
Comparison:
https://github.com/jpkrohling/rhq-metrics/compare/rhq-project:master...jp...
If you'd like to run this on your local machine, I'll need to build
Keycloak from master by yourself, as I'm using a feature that was
added this week.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJUgZbuAAoJECKM1e+fkPrXZf4H/1h58HL51UyrYqqM/gPhMAt0
EcY4P8/I4HwSpAw1AO8BnR2TL+EgZc+bAZn7Nw/NrOH61eU5IGVG5+UcnqS7LIP9
m8NteACuyJhfTmKly8PNxENQ0grCjOoUpAffN97pbFoJWT/MKlzda4dAbL7aAN05
Kgz99OvqFWJMLGOtQWcvEiZBDU+OacY9NBkKXCl0ZivnN47YonA0c3SLlnG8a+34
4NErQbSpm7iENPz2ab4EbCbRduGoQtu8NtKclnweAkD3MurfRHSvRKckib0MgASM
LRE9B2nt+MMekeN6I9Q2UrTY9hP4X9xIEpWHy+KXKMI4vHb9xxyFiIC/Kly2boY=
=fVaW
-----END PGP SIGNATURE-----
9 years, 3 months
No concept of a platform?
by Heiko Braun
Guys, ay what point do you want to start thinking about a platform for all the bits and pieces you throw together? Possibly even a platform that supports coordinated multi-node deployments and operations?
How do you think is a bunch of EAR’s and WAR’s creating a coherent whole at the end?
I can understand that Wildfly might not be your first choice for achieving this. But we did great length to make sure some your basic requirements are covered. I still believe wildfly-core would offer a reasonable baseline for RHQ metrics and related projects. But it seems to me that you cannot or just don’t want to see the value in it.
If you have another proposal for a managed runtime, bring it up, but please don’t tell me that your idea of a system architecture is limited to a servlet container.
The more developer-centric artefacts you create, the less likely it becomes to integrate as managed, secure and scalable system at the end. I know integration is the Cinderella of software development, but if you don’t account for it from the beginning it’s very unlikely to happen at the end.
RHQ metrics started on good grounds, with several reasonable approaches to things. But the project’s structure degrades the more things you slam onto it.
I hope this email creates room for another discussion. About the big picture, about the system architecture for RHQ metrics and integration options for projects like Wildfly that have been looking forward to it so far.
Regards, Heiko B.
9 years, 3 months
License headers
by Peter Palaga
Hi *,
as some of you may know I asked RH Legal some time ago about the text of
our license header. I got the reply now and am going to work on both
fixing the present license headers, adding them where they are still
missing and setup a maven plugin for checking the presence of headers
during the build. I plan to do this for Metrics first and when I am done
I either ask other Hawkular projects to follow the same pattern or I do
it myself.
Best,
Peter
9 years, 3 months
[rhq-metrics] Use of tenant id's / tags
by Heiko Braun
If we have the same metric from different sources (i.e. same service on different hosts), would tenant id’s be used to distinguish the sources or tags?
/heiko
9 years, 3 months
QOTD
by Heiko W.Rupp
https://twitter.com/tetradian/status/495692008930181120
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
9 years, 3 months