right now we are using JUL for logging. That works fine, so far :-)
However related projects (e.g. Keycloak / LiveOak) are using JBoss Logging.
I somewhat feel that it's perhaps not a bad idea if we would use JBoss
logging as well...
I know there are a gazillion different Java logging frameworks out there
(yikes), but my question is really: keep JUL or go with JBoss-Logging :)
Good morning slackland, yesterday I had a hangout with Matthias and we agreed that the whole key agreement thing would bring more complexity from the developer’s pespective. That’s the reason why the client with airline was dropped.
Here comes the new proposal: https://gist.github.com/abstractj/ef1e3d53619796f4e87e
# Passphrase encryption for UPS
**Note**: This is NOT a replacement for SSL
- Developers wants to upload passphrase and certificate for iOS variants. The passphrase must be stored encrypted and restored in clear while sending messages.
## Jira references
- https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout with Matthias, we agreed that would complicate the developer's workflow.
Today we can't guarantee that our developers will have an [HSM](http://en.wikipedia.org/wiki/Hardware_security_module) to manage encryption keys. Neither we can store the private keys in a separated database, for the push server.
If somehow the database is compromised, private keys could be exposed and most of the sensitive data decrypted.
The suggestion is to make use of a *KDF function* per application to encrypt passphrases, not perfect, but helps (like we did in the past for password reset). Where encryption key means:
PK = PBKDF2(Secret Key, Salt)
*Secret Key*: In the ideal world, users would be required to provide a password for encryption. In this scenario we don't want them to be prompted to input the password, or add extra parameters to the UPS endpoints. So the suggestion is to provide secret key configured on the server and protected by the ACL's from the operating system
*Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the server per application and stored into the database.
### Secret key configuration
The file can be generated and checked if something exists during the application start up.
secret_key = "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \
### Sending push messages
Passphrases must be reversible for Apple, that's why we make use of symmetric encryption here.
# REST API
## Register push app
```POST | rest/applications```
### HTTP request
### HTTP response
## iOS Variant
### HTTP request
### HTTP response
### HTTP request
### HTTP response
No changes at the client side.
I've drafted a few checklists for QE to go through for community releases
(UPS, OS Cart, Cordova Push Plugin). I've put them there:
Any feedback on their content is very welcomed.
As for the location, I think the best way would be to put them directly into
GH repositories, for instance into RELEASE.ad / RELEASE.md file, together with
release process instructions (not existing yet). General testing instructions,
applicable for any project, can go to aerogear-parent or aerogear-testing-tools
and be crosslinked.
here is a little summary of some of the things the JS team discussed
JS Cool Team Stuff
1.5.0 - Early May
MQTT WS adapter
More Cookbook examples
UnifiedPushClient jQuery Removal
we need to polyfill it - pack that into client https://github.com/jakearchibald/es6-promise
1.6.0 - Mid July
stalled, conversations started again
is going liveoak to work on data sync?
keycloak examples mention private key in a client code
1.7.0 - Late September
application cache is still a douchebag
ES6 modules(?) - transpile
maybe include in 1.6/1.7
we could leverage in custom builder, possibly
challenge: compatibility w/ AMD / commonjs (UMD?)
Current Road Map
2.0 collect ideas what people might struggle with?
pipelines - frameworks use usually own stuff
improving documentation and getting started experience
getting started with AG + particular web frameworks
examples -> cookbook (complete stack)
move tests to jasmine or something other than qunit(?) - not sure what the benefit could be
move docs to something other than jsdoc, ex: yui doc - not sure what the benefit could be
<push onevent="..." />
I would like to release another version of the cordova push plugin (next week thursday), the major feature will be the new simplified API that is already on the master branch and there have already been successful builds. Releasing it will update the version to 0.0.4 and make it available on the registry, it would also provide a test for the gradle release script.
(next try, sorry again)
some time ago there was already a discussion about using Android Studio / Gradle
, but as far as I can see nothing happened afterwards.
So I was curious if I can get the cookbook application running with Android's
new build system, and want to share what I found out so far:
My first approach was to migrate the cookbook first, and using the library as
dependency only. But that didn't work out, because the Androd dependencies in
the pom.xml of the lib could not be found. I really didn't want to install them
with the maven-android-sdk-deployer, because that's not needed anymore with the
new build system, it accesses directly the installed Android SDK.
So I migrated the lib first. The first issue was: how do I get the aar into my
local maven repository? Solution: the Gradle Android Maven plugin . After
some configuration I could install the lib into my local maven repo with
"gradlew clean install". Nice.
Then I looked how I can run the Robolectric tests in the lib. That seems to be a
problem, because the Android Gradle plugin team seems to be focused on running
tests in AVDs or on real devices only . Then I found another Gradle plugin to
the rescue... at least I thought: the Robolectric team itself maintains the
Gradle Android Unit Testing plugin , which should run JUnit and Robolectric
tests, but unfortunatly it was broken by the latest Android Gradle plugin
update... . So I prepared running the tests, but had to comment out the
plugin for the moment.
So back to the cookbook: here I had to use a workaround now for accessing my
local maven repo, because the official and easy way is broken in Gradle itself
atm . But with the workaround I could run the cookbook app on my device with
"gradle clean installDebug"... finally (And with the OpenShift Push Server it
was easy to test the push functionality, great!)
So my resume of this adventure:
before that I liked Android Studio very much, I used it for some little private
fun apps already, and had only few problems. It has features (e.g. product
flavors) which were more difficult to handle with maven. But I tested only by
deploying and using the apps on my own devices (shame on me, I know...), so
missing JUnit/Robolectric support was not an issue for me. And my library
project was part of the app's project (works nice with Gradle!), so no local
But now I think that there is still some work to do with Android Studio and the
Android Gradle plugin. Some gaps can be filled with 3rd party plugins, but the
chance that they get broken by new versions of the build system is not low,
development is very fast.
One point I forgot: I did not have a look into the Travis stuff, because I don't
know it yet.
If you are interested in my results, see here:
aerogear-dev mailing list