UPS Admin Console - migration to AngularJS
by Sebastien Blanc
Hi all,
As you might know, it has been decided to migrate from Ember/TopCoat to
AngularJS/Bootsrap/Patterngly for the UPS Admin Console.
Hylke is currently working on HTML/CSS mockups, and in the mean time, I
started to preparation work for the AngularJS migration.
Before I go on PTO, I would like to share that with you ;)
In this branch :
https://github.com/sebastienblanc/aerogear-unified-push-server/tree/angular
I have created a new folder "newadmin" containing an pretty empty Angular
project. I kept the old "admin" to make the migration easier but in the end
of course, the "newadmin" will be merged with the old one.
There is not too much in it but enough to start the migration. It's a
layout generated by yeoman for AngularJS.
I've adapted the Grunt file the same way Luke did for the old console,
meaning that you can point to your deployed WAR and having you changes
reloaded live. That make the development a way easier.
Don't forget to do a "bower install" and "npm install" before doing "grunt
server" , the first time you run it the script will break and you will have
to fill in the generated "localConfig.json" file (to point to your
Wildfly/jboss UPS deployed WAR).
I've just created one Angular Service to do the CRUD operations on
Applications and Variants.
There is also one controller "MainCtrl" which retrieves the list of
Applications and shows them in a table on the view. => That is just to show
how the flow should go and help going further.
Because we are also migrating to KeyCloak , I did not put any effort into
the Login interaction. Therefore when the apps load, it logs in
automatically. Be sure to set the right password in "app.js" and also the
app expects to have a password that is already "confirmed". If you are
using a fresh DB, please do the "first login + reset + confirm" dance with
curls.
So, I have this will help for starting with the migration.
See you later !
Sebi
10 years, 8 months
Push server...master secrets, secrets and some refactoring proposal
by Bruno Oliveira
Good morning, while I was working on "that" passphrase encryption thing,
I found some improvements for UPS. But would like to discuss before.
1. Currently UPS stores master secret and secrets (from Variants) into
the database. IMO this information should never be persisted into the
database and such kind of information only belongs to the owner of that
application. How?
https://github.com/abstractj/aerogear-unifiedpush-server/tree/master-secret
2. Master secret and Secret make use of UUID from Java, not truly a PRNG
once some attributes are predictable, you are not collision free. "WTF
are you saying Bruno!?". From JDK 7:
|public static UUID randomUUID() {
SecureRandom ng = numberGenerator;
if (ng == null) {
numberGenerator = ng = new SecureRandom();
}
byte[] randomBytes = new byte[16];
ng.nextBytes(randomBytes);
randomBytes[6] &= 0x0f; /* clear version */
randomBytes[6] |= 0x40; /* set to version 4 */
randomBytes[8] &= 0x3f; /* clear variant */
randomBytes[8] |= 0x80; /* set to IETF variant */
return new UUID(randomBytes);
}|
Solution:
https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35e...
3. I noticed the fact that PushApplication and Variant have some
duplicated attributes with different names.
public abstract class Variant extends BaseModel {
private String variantID = UUID.randomUUID().toString();
private String secret = UUID.randomUUID().toString();
....
}
public class PushApplication extends BaseModel {
private String pushApplicationID = UUID.randomUUID().toString();
private String masterSecret = UUID.randomUUID().toString();
...
}
I can see two alternatives to avoid it:
- Move these attributes to an |Embeddable| class, something like:
|@Embeddable
*public class ApplicationKey*{
| private String id = UUID.randomUUID().toString();
private String secret = UUID.randomUUID().toString();
|
}|
public abstract class Variant extends BaseModel {
| @Embedded
@AttributeOverrides( {
@AttributeOverride(name="variantID")),
@AttributeOverride(name="secret"))
})
*private ApplicationKey*key;|
....
}
public class PushApplication extends BaseModel {
|@Embedded
@AttributeOverrides( {
@AttributeOverride(name="pushApplicationID")),
@AttributeOverride(name="masterSecret"))
})
*private ApplicationKey*key;|
...
}
- Second alternative (more simple) pull up the attributes to BaseModel
public abstract class BaseModel implements Serializable {
private String id = UUID.randomUUID().toString();
private String secret = UUID.randomUUID().toString();
...
}
Why this is important?
1. Avoid sensitive data to be stored into the database, make use of KDF
functions to store secrets, master secrets....
2. Avoid code duplication. With the inclusion of encryption for
passphrases and other kind of sensitive data, I pretty much have to
duplicate code like this
(https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35e...)
between both classes.
Wdyt?
--
abstractj
10 years, 8 months
UPS UX updates
by Hylke Bons
Hello,
https://github.com/hbons/aerogear-design/tree/master/ups-new-ux
The above link contains mockups with an updated look and feel.
I've tried to consolodate the info that we had on different pages on
fewer pages, as a common critique was that the Application Details and
Variant Details pages looked alike too much, so I've merged them.
On one page I've added a sidebar that reflects future features (it's
just for show).
Other notable things are the orange info blocks where we want app
developers to take action on information (the device registration and
sending notifications in this case). I've deliberately made these stand
out a bit more as we want people to act on the information. Please note
that one row in the variants table shows up expanded in the mockups for
illustration purposes. The rows will all be collapsed on first view, so
it won't look as cluttered as you might think at first seeing the mockup.
Let me know what you think and where we should go from here.
Thanks,
Hylke
10 years, 8 months
Aero push iOS 64bit?
by johnbran
Hello,
I am running xcode 5.1 and cordova 3.4. When I test my app on an iPhone 4
it works without issue. When I run it on an 5s (64bits) or in the 64bit
iphone simulator I get the following errors...
ld: warning: ignoring file
/Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a,
missing required architecture x86_64 in file
/Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a
(3 slices)
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_AGDeviceRegistration", referenced from:
objc-class-ref in PushPlugin.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
If I choose to compile only to 32bits using $(ARCHS_STANDARD_32_BIT) in the
Architecture build settings, Cordova throws errors.
Does Aero push for iOS support 64bits? I got it working nicely in Android
and would like to use the same system for iOS.
Thanks
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-tp7258.html
Sent from the aerogear-dev mailing list archive at Nabble.com.
10 years, 8 months
HelloWorld images
by Corinne Krych
Hello All,
For our HelloWorld demo apps, we agreed on an unified Ui looks, although really simple. It would be nice to have unified images.
As discussed with @edewit sticking to png is easier for native app. We need icon and launch image.
we have an icon image but what could be used for launch screen?
For iOS7 here is the size needed:
icon 58x58
icon 80x80
icon 120x120
launch image 640x960
launch image 640x1136
What about Android?
So who feel like doing the images for all clients? (looking for an artist)
++
Corinne
10 years, 8 months
Geotagged notifications
by Miiguel Lemos
Geotagged notifications are a very relevant component of any service of push notifications.
First of all, because of marketing reasons: when a notfication is received in the scope of a given geofence (for instance the proximity to a venue, store, etc.) the probability of the user react to it is much bigger.
Using other technologies (other than GPS, cell towers, Wi-FI, etc) - I can come back to this later - you can also use location based services for automated in-house check-ins and subsequent events (many...).
Basically there are two ways of managing geotagged - I'd prefer to say location based - notifications:
A) The phone sends periodically its location to a server and the backend sends to the phone - via Google, Apple, whatever - the push not;
B) The server sends to the phone all the geotagged notifications it has for a given user or group, and te terminal itself checks locally if the location criteria are matched, triggering the local notification if that match occurs (considerang also the radius, accuracy of the coordinates, etc.)
At this moment I'll not elaborate more ore on this, but the second way has several advantages over the first.
Of course the second method has several implications, namelly in the flow of the service, but if you want we can talk about this later.
Other issues, like battery drainage, privacy matters, etc. must also be taken into account in the solution implemented...
Miguel
Enviado do meu iPad
10 years, 8 months
UnifiedPush Server: Hello World- and Quickstart Examples
by Matthias Wessendorf
Hello there,
we recently had talks about creating some simplified quickstarts and
hello-word demos, related to the UnifiedPush Server and JBoss AS developers:
* Hello World (No Server Code - just client receiving push, no fancy
(complex) UI on the client, nor integrated into a Cookbook or something
that has "dependencies")
** Cordova
** Android
For iOS that is already there:
https://github.com/aerogear/aerogear-push-ios-demo
Yes, just usage of the "Push Registration SDKs", is the goal here: keep it
simple, since native push can be a complicated use-case all on its own and
so it will be good to make sure we cover the basics here.
Beyond the Hello-World, we wanted some different quickstarts. The "server"
components that come to mind would be:
*Secured CRUD + Push Integration (Java Sender)
** JAX-RS + PicketLink
** SpringMVC/Spring Security
** JAX-RS + Apache Camel
These need to function on both JBoss AS 7.X and EAP.
Josh, from the JDF team, has already said he wants to help on the server
projects (especially the JAX-RS/PL and Spring ones). yay!
Note: Josh already has a simple backend started that is used in JDF
quickstarts that would be good to re-use to make it easier for developers
to transition from one to other.
The goal would be the SERVER acts same to outside (identical REST
endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs.
Camel))
For these different servers, there would be mobile apps needed:
* Android
* Cordova
* iOS
The idea would be to keep them simple and straightforward as well, e.g. for
iOS that means plain usage of NSURLConnection / NSURLSession. But for the
"push registration" of the client,
the iOS-push SDK would be used (same/similar would apply to Cordova or
Android). Similar to the above 'Hello World', the quickstarts are going to
be focused only on Push functionality, so for these we would leave out
pipes and such until later versions.
I will be creating Epics and subtasks in JIRA for this.
For the location of all these projects, I had this "uber repo" location in
mind:
* https://github.com/aerogear/aerogear-push-helloworld
* https://github.com/aerogear/aerogear-push-quickstarts
Greetings,
Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 8 months
