SPEC: AeroGear Unified Push Server
by Matthias Wessendorf
Hi,
I started a GIST to convert the different gists and readme's into a
server-side spec
(https://gist.github.com/matzew/b918eb45d3f17de09b8f)
* Regarding the "mobile variant instance":
We need to decide, what a SimplePush client may need on-top of the data,
described below (and in the gist). (since they have clientIDs + channels)
* Similar... we need to reflect the "" on a "selected" (and broadcast) send
as well.
* Sec: there is a different meeting, on the sec - content will be
integrated (or linked from this spec)
If this doc, looks good, I will submit it as a PR so that we get it on the
homepage
Next:
CLIENT SPEC is coming later today (or tomorrow)
Thoughts ?
Matthias
AeroGear Unified Push Server (Draft 0.0.3)
The *AeroGear Unified Push Server* is a server that allows sending native
push messages to different mobile operation systems. The initial version of
the server supports Apple's
APNs<http://developer.apple.com/library/mac/#documentation/NetworkingInternet/...>
, Google Cloud Messaging<http://developer.android.com/google/gcm/index.html>
and Mozilla's Simple Push <https://wiki.mozilla.org/WebAPI/SimplePush>.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#motivation--purpose>Motivation
/ Purpose
*Goal*: Any (JBoss/AeroGear powered) mobile application, that is backed by
JBoss technology (e.g. admin console, Errai, drools, etc.), is able to
easily work with mobile push messages. For a JBoss "backend application" it
should be as simple as possible, to send messages to its different mobile
clients.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#definitions>Definitions
Before we get into details, it's important that we have a good lexicon.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#push-application>Push
Application
A logical construct that represents an overall mobile application (e.g. Mobile
HR).
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#mobile-variant>Mobile
Variant
A mobile variant of the *Push Application*. There can be multiple variants
for a *Push Application* (e.g. HR Android,HR iPad, HR iPhone free, HR
iPhone premium or HR Mobile Web).
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#mobile-variant-instance>Mobile
Variant Instance
Represents an actual installation on a mobile device (e.g. *User1 connected
via MobileWeb* or *User2 runs HR iPhone premium on his phone*)
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#overview>Overview
The *AeroGear Unified Push Server* contains three different components:
- Registration: *Registry for Push Applications, Mobile Variants and Mobile
Variant Instances*
- Storage: *A database, storing the registered applications and instances
*
- Sender: *Receives messages and sends them to different Mobile Variant
Instances*
The graphic below gives a little overview: [image:
components]<https://a248.e.akamai.net/camo.github.com/11b903b1eea5c2ba492ee4ec759b205...>
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#functionality>
Functionality<https://gist.github.com/matzew/b918eb45d3f17de09b8f#registration>
Registration
Three different registration types are provided by the *AeroGear Unified
Push Server*.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#push-application-regi...>Push
Application Registration
Adds a logical construct, that represents an overall mobile application
(e.g. Mobile HR). The *Push Application* contains the following properties:
- Name
- Description
- A collection of Mobile Variants
The server offers an HTTP interfaces to apply a *Push Application*
registration:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"name" : "MyApp", "description" : "awesome app" }'
http://SERVER/applications
*The response returns an ID for the Push Application.*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#mobile-variant-regist...>Mobile
Variant Registration
Adds a *mobile variant* for an *existing* *Push Application*. There can be
multiple variants for a *Push Application* (e.g. HR Android, HR iPad, HR
iPhone free, HR iPhone premium or HR Mobile Web).
The server supports the following variant types:
- iOS
- Android
- SimplePush
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#ios-variant>iOS Variant
An iOS variant represents a logical construct for one iOS application (e.g. HR
for iPhone *or* HR for iPad ). The iOS variant requires some APNs specific
values:
- APNs Push Certificate file
- Passphrase
The server offers an HTTP interfaces to register an *iOS varian*:
curl -i -H "Accept: application/json" -H "Content-type: multipart/form-data"
-F "certificate=(a)/Users/matzew/Desktop/MyCert.p12"
-F "passphrase=TopSecret"
-X POST http://SERVER/applications/{PUSH_ID}/iOS
*NOTE:* The above is a *multipart/form-data*, since it is required to
upload the "Apple Push certificate"!
*The response returns an ID for the iOS variant.*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#android-variant>Android
Variant
An Android variant represents a logical construct for one Android
application (e.g. HR for Android). The Android variant requires some Google
specific values:
- Google API Key
The server offers an HTTP interfaces to register an *Android variant*:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"googleKey" : "IDDASDASDSA"}'
http://SERVER/applications/{PUSH_ID}/android
_The response returns an ID for the Android variant.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#simplepush-variant>SimplePush
Variant
An SimplePush variant represents a logical construct for one SimplePush
application (e.g. HR mobile Web). The SimplePush variant requires some *Simple
Push Network* specific values:
- URL of the PushNetwork server
The server offers an HTTP interfaces to register an *SimplePush variant*:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"pushNetworkURL" : "http://localhost:7777/endpoint/"}'
http://SERVER/applications/{PUSH_ID}/simplePush
*The response returns an ID for the SimplePush variant.*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#mobile-variant-instan...>Mobile
Variant Instance Registration
Adds an *mobile variant instance* to an existing *mobile variant* (e.g.
User1 runs HR-iPad on his device). It is possible that one user can have
multiple devices. A *mobile variant instance* contains the following
properties:
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#required-data>Required
Data
- *deviceToken*
*The platform specific device token, that identifies the device with the
used push network, in order to deliver messages*
- *operatingSystem*
*It is required for the device to submit it's exact name of the underlying
OS.*
- *osVersion*
*It is required for the device to submit it's exact version of the
underlying OS.*
- *Mobile Variation ID*
*ID received when registering a Mobile Variant. This ID needs to be
submitted as a request header (ag-mobile-variant). NOTE: It is possible
that this ID goes away, in favor for a digital signature in a future release
*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#optional-data>Optional
Data
- *deviceType*
*It is recommended to store the (exact) device type (e.g. phone vs tablet).*
- *alias*
*If the business application requires the conecpt of a user, the
registration must submit an unique identifier (like a username), to
identify the user. It is possible that one user has multiple devices.*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#business-data>Business
Data
The above are technical information bits that are required to get a message
to the device. This the app wants to send notification based on a criteria,
the relevant data has to be stored in the business backend. This way the
backend app is very flexible on the criterias (e.g. max salary,
geolocation, number of children, etc). All this data is NOT directly
related to the technical functionality of sending data. The usage of the
AeroGear Pipe is *highly recommended* to store business data on the
business backend.
The server offers an HTTP interfaces to register an *mobile variant instance
*:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-H "ag-push-app: {id}"
-H "ag-mobile-app: {id}"
-X POST
-d '{
"alias" : "user(a)company.com",
"deviceToken" : "someTokenString",
"deviceType" : "ANDROID",
"mobileOperatingSystem" : "android",
"osVersion" : "4.0.1"
}'
http://SERVER/registry/device
*NOTE*: Platform specific Client SDKs will be provided to submit the
require data to the *AeroGear Unified Push Server*.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#storage>Storage
A (configurable) database that stores all registered applications and
instances.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#sender>Sender
HTTP interface that receives messages for a delivery to different Mobile
Push Networks. A few different *Sender Types* are supported by the push
server.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#global-broadcast-sender>Global
Broadcast Sender
Sends a push message to all *mobile variants* (and all of its *mobile
variant intances*), of a given *Push Application*:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"key":"blah", "alert":"HELLO!"}'
http://SERVER/sender/broadcast/{PushApplicationID}
Sends a JSON map to the server. If platform specific key words (e.g. alert
for APNs) are used, they are honored for the specific platform. This
transformation is done by the *AeroGear Unified Push Server*.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#variant-specific-broa...>Variant
specific Broadcast
Sends a push message to only one *mobile variants* (and all of its *mobile
variant intances*).:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"key":"blah", "alert":"HELLO!"}'
http://SERVER/sender/broadcast/variant/{MobileVariantID}
Sends a JSON map to the server. If platform specific key words (e.g. alert
for APNs) are used, they are honored for the specific platform. This
transformation is done by the *AeroGear Unified Push Server*.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#selected-sender>Selected
Sender
Sends a push message to a selected list of identified users (regardless of
their variant):
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
alias: ["user(a)foo.com", "bar(a)moz.org", ....],
message: {"key":"blah", "alert":"HELLO!"}
}'
http://SERVER/sender/selected
The alias value is used to identied the desired users. The payload (messages)
is a standard JSON map. If platform specific key words (e.g. alert for
APNs) are used, they are honored for the specific platform. This
transformation is done by the *AeroGear Unified Push Server*.
11 years
OTP.js
by Bruno Oliveira
Morning slackers, I had a meeting with Kris, Luke and Passos about the painless way to provide an OTP implementation for JavaScript.
https://gist.github.com/abstractj/d618faceee388a9d403a
Basically the scenarios 1 and 4 were chosen to be implemented. Scenarios 2 & 3 would provide bad user experience.
I'll start to file some Jiras to myself, if you have any addition, let me know.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
11 years, 1 month
Cookie Management specifically Authentication
by Summers Pittman
Y'all,
Currently in the demo app (controller-demo) when ever we authenticate a
cookie is set to manage the session. When we log out the cookie is expired.
On the client side this means we need to manage the cookies somehow.
This is done automatically for Android and Javascript when the logout
URL is accessed. On Android this access happens via the logout method
of AGAuthenticationModule (via a HTTP GET).
In the case of HTTP Basic authentication, however, logging out is simply
expiring the credentials the user is using on the client side. IE the
API should stop caching and sending them. However, because cookie
management is automatic and global (currently and also by design in
Java) when the controller demo sets the session cookie the cookie store
(for the domain) must be explicitly tossed. I don't think this is the
correct thing to do.
From my perspectives there are a few options.
1) Http-Basic authentication on the server should NOT create a session
and the client should NOT expire the cookie store when logout is called
on a HttpBasicAuthenticationModule instance.
2) Http-Basic authentication on the server WILL create a session and the
client WILL expire the cookie store when logout is called on a
HttpBasicAuthenticationModule instance.
3) Http-Basic authentication on the server WILL create a session AND
provide a key name and the client WILL expire the cookie value for the
key when logout is called on a HttpBasicAuthenticationModule instance.
4) Abstractj comes up with a brilliant idea I haven't thought of.
Summers
11 years, 1 month
[Aerogear Pipeline] Support for nested endpoints
by Sebastien Blanc
Hi,
While I was playing with scaffolding and tried to build a simple Blog
Application with Aerogear I faced the current situation :
I have a *Post* object which contains many *Comment* objects. Now I want to
call my Post pipe to retrieve the related comments, I have currently 2
options :
*
*
*/posts/1* -> assuming comments will be implicitly retrieved (eager loading)
*/comments/?postid=1*
But regarding our model the correct form should be :
*/posts/1/comments*
*
*
But, AFAIK, with the current API, it is not possible to define this last
pattern (at least for JS and iOs, confirmed by Matzew). When doing a *read
*we can pass an *id *option but as mentioned in the doc, this id will
always be append to the endpoint.
IMO, we should be able to support this pattern but for now I'm not really
sure how to specify this in our API, so if you have any ideas feedback this
thread has been made for you !
Seb
11 years, 1 month
Re: [aerogear-dev] Google Summer ofCode
by Bhargav G
Sir,
Thanks for your help. I have subscribed to Aerogear Dev Mailing List. I
will definitely go through the repo you shared and will develop my proposal
with its help.
And by socialnetwork integration, I was talking about the description about
this project presented here:
https://community.jboss.org/wiki/GSOC13Ideas?_sscc=t#Demo_Implementing_na...
It is said that the app should be added with social network integration
feature. I couldn't understand what exactly is required. Is it just that a
user should be able to login with Facebook/Twitter account?
On Thu, Apr 18, 2013 at 8:27 PM, Matthias Wessendorf <matzew(a)redhat.com>wrote:
> Hi Bhargav
>
> thanks for the interest in JBoss and AeroGear. I am part of the AeroGear
> team and replying on behalf of Jay Balunas
>
>
> >I got a few questions.
> >Could I get a link to existing app's repo so that I can get an idea about
> the level of implementation?
>
> The AeroGear repo is here: github.com/aerogear - more information on
> aerogear.org :)
>
> >Currently there are phonegap plugins for geolocation, camera and photo
> management and contacts handling. But I don't understand what you mean by
> Social Integration. Is it like
> >logging into Facebook/Twitter to post into them? I think I would get a
> better idea about it if I get to look at existing app.
>
> Not sure I fully understand that question. Can you point me to the
> specific section ?
>
>
> >I would be very much obliged if I am provided with answers to these
> questions and whatever questions that may arise in future as they will help
> me in writing a good proposal and in turn get chosen to jBoss.
>
>
> Thanks again for the interest! Can I recommend to join our Open Source
> mailing list ?
>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> We can (and should) discuss details there. Part of GSoC is not only to
> build things, it's also there to "learn" Open source, and interacting with
> OS communities.
>
>
> Greetings,
> Matthias
>
>
> --
> Matthias Wessendorf
> matzew(a)redhat.com
>
> JBoss, by Red Hat
>
11 years, 1 month
nested path - testbed
by Christos Vasilakis
Hi team,
as we discuss in the meeting, we need a testbed app to go against our integration tests for the nested path feature. For this there are two options:
a) either enhance our currently TODO app and add support for schemas of "/projects/{id}/tasks/{id}/tags{id}". Currently ag-controller supports nested path params.
b) create a separate and simple app eg. a blog engine with /blog/{id}/comments/id} etc. so that we point our tests there.
The advantage that a) gives is that we don't need to write and maintain a separate app, but we may need some different behaviour that doesn't cover either TODO or controller's functionality (eg. upload file functionality on the Pipe etc). So I am more in b) so that we can use it as a general testbed for the features we want to implement (now and in the future.)
Wdyt?
Thanks,
Christos
11 years, 1 month
Pushing into the Open
by Kris Borchers
In the interest of keeping things open and not working in a black box, Dan, Matthias and myself would like to give a quick update on some of the push related work we have been doing and continue to do. We are still very much in the PoC phase and are trying to get some working examples going for everyone's review. In the meantime, here is where we are.
Unified Push
Matthias has done a lot of work on a PoC for a Unified Push server which will allow for sending push messages (iOS and Android based native push as well as web push) to clients. Currently, this is done via a REST based interface that allows for sending a single message payload to an endpoint which is then disseminated to the registered client devices/browsers.
SimplePush
In the Unified Push section, I mentioned the ability to send push notifications to web based clients as well as native. As I'm sure most of you are aware, this isn't really possible ... yet. Mozilla has been working on a SimplePush[1] API spec which will allow native-like push messaging in broswer-based applications. They are currently close to a first implementation landing in FirefoxOS with plans for it to land in Desktop and Mobile Firefox later this year. Without going into too much detail, this looks really promising and so we have decided to start working on both a client library which would act as a pollyfill for the native browser functionality, not only in Firefox but all browsers including mobile, and a SimplePush Server which would act as sort of the push "network" which Firefox is providing for its native implementation. We started out with a client implementation that acted less like a pollyfill and more like a piece of AeroGear.js which isn't a bad thing, but didn't seem as useful. I have rewritten it to follow the spec and am much happier with where it is so far. Dan has been pulled in to start working on the SimplePush server bits and his early work looks promising as well. Our goal to start with is to get a few of the basics in place, like doing the SimplePush handshake/hello, registering channels, and then handling push notifications to the registered channels. This will all be a lot easier to explain when we have examples to show, and we hope to have something soon, hopefully in the next week or so.
The three of us are really excited about the possibilities here and hope we can get you all just as excited. Stay tuned as we will be keeping everyone up to date here on the mailing list as we progress.
Thanks!
Dan, Matthias and Kris
[1] https://wiki.mozilla.org/WebAPI/SimplePush
11 years, 1 month
