Push Server: Database: Storing data for an application installation (per device)
by Matthias Wessendorf
Hi folks!
As discussed a few times, we have the following "high-level" construct of
data (required for push):
- PushApplication ("HR Mobile")
- MobileApplication ("HR for iPhone", "HR for iPad", "HR for Android")
- Installation ("Matthias uses iPhone HR", "Matthias uses Android HR",
"Bruno uses iPad HR")
(More details here <https://gist.github.com/matzew/6012edf62d1915689a67>)
<https://gist.github.com/matzew/04346e212e317d976532#data-per-installation...>Data
per installation per device
Now, thinking about what to store for an actual device gives you lot's of
choices. For instance, Helios/Orbiter stores a lot of information in the
"device" database (e.g. (current) Location Data, Locale etc).
Like you can see here:
[image: Helios Web UI
Screenshot]<https://raw.github.com/helios-framework/helios.io/assets/helios-screensho...>
All the information is really app specific (e.g. not every app needs to
know the current location...); (A side-note... our client SDK should be
flexible to store what ever the application requires...)
<https://gist.github.com/matzew/04346e212e317d976532#mandatory-data>Mandatory
Data
Regardless of what data is desired or not, the following is the minimum
that needs to be stored:
- Device Token (generated by the PushNetwork (e.g. APNs, GCM) - used to
identify the device with the actual Network, so that it can send a message
to that device)
- OS and Device Type (we need to store if this is an installation of the
iPad version, the iPhone version or the Android version (to use the above
HR example))
- OS Version (the version, never hurts)
This is the minimum of data, required to store in our "device registration"
database;
As discussed in AEROGEAR-1101<https://issues.jboss.org/browse/AEROGEAR-1101>,
I would like to store the above "device" data, using the Picketlink IDM
(Actually the entire data base (PushApplication, MobileApplication and
Installation("device")).
<https://gist.github.com/matzew/04346e212e317d976532#user-data->User Data ?
Now... you might wonder if there isn't any user data required ..... Well,
that is also up to the application and how works.
Overall, I see the following two common application models, suppored by the
*Push Server*:
- device has a user (a known user in an Application (e.g. Marketing)
Databases)
- device has *NO* user (no need to have a user for the app)
<https://gist.github.com/matzew/04346e212e317d976532#user-required>User
required
This would be an app, that requires an account, before it can be used on
the device (e.g. something twitter). For applications like that, a user is
required, otherwise hard to send a Push Notification to a specific user
(e.g. "You have new tweets") ( *Also twitter works only with a user, on
their "application backend/database"* )
<https://gist.github.com/matzew/04346e212e317d976532#no-user-concept-on-th...>No
User concept, on the backend
That's a (very) simple app. Think *Sports App*. The app displays "sport
news" (fetched via HTTP, when the app is opened). A installed application
can also receive "broadcasts messages".
*Scenario:* You download the app in the app store, install it, use it; When
ever the backend thinks it needs to send Notifications (eg. "New score 3:1
at Germany - Brazil"), it simply uses the token and submits the message to
the actual Push Network. For applications like this, the backend does not
need a user;
<https://gist.github.com/matzew/04346e212e317d976532#application-with-user...>Application
with User required
Now, let's comeback to the apps, where a user is required, in the backend.
Somehow the business backend (e.g. HR system) needs to identify a certain
user (and their devices), so that it can "submit" Push Notification jobs.
Bruno, Shane (from Picketlink) and I talked already to store something like
a unique ID (e.g. user-id, login-name or user-name) in the "Device" Table
(per device):
TOKEN | user | DEVICE-TYPE | OS-VERSION
_________________________________________________________________________
823ssar | abstractj | Android | Android4.x.y.blah
1234456 | mwessend | iPad | iOS4.0.1
ghh2712 | mwessend | iPhone | iOS6.1.2
Doing so, we can use that "unique ID" to *bridge* between the actual
"application database" and the stored informations about the device(s),
stored in the *push-server-database*; per user!
*NOTE* Since the Push Server (and the "device database") is a standalone
server (access via HTTP / Java Library), the real (business) backend (e.g.
HR App), can than say:
*Send message X to to following users* (a list of unique user IDs would be
send to the push server, so that the Push Server submit these messages to
the actual Push-Networks (ANPs/GCM)so that Apple and Google (for
iOS/Android) can deliver the actual notification to the client/device.
<https://gist.github.com/matzew/04346e212e317d976532#client-sdk>Client SDK
Again, As said above, we should (and will) offer hooks to have a convenient
way to register the unique ID, together with the token,OS,version etc. *BUT*
*that is not that important here... ;-)*
*
*
*Thoughts?*
*
*
*
*
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 11 months
Using IDM for storing device informations (was: Re: Push Server: Database: Storing data for an application installation (per device))
by Matthias Wessendorf
Hi, as mentioned in
AEROGEAR-1101<https://issues.jboss.org/browse/AEROGEAR-1101> we
are looking into using the IDM for storing the "data model";
I created some hacky/ugly project to start playing with IDM for my "device
installations"
https://github.com/matzew/IDM-tests
I am having a custom "agent" there,.... however I see the point (by Shane
on PL's IRC channel) that perhaps the Agent is not right, since the device
CAN (see my other email) have a reference to a user (in that case the
device would be just an "add-on" / "extension" of the user).
Also, besides the device data, we should/need to store the "application
abstraction" model (see other email) in the IDM as well Like:
One PushApp (HR mobile) has two mobile apps (HR-iOS, HR-Android) each of
the mobile apps has "installed" apps (bruno uses iOS version, on his iPad;
I use android on my other Tablet)
Greetings,
Matthias
On Wed, Apr 17, 2013 at 10:39 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> Hi folks!
>
> As discussed a few times, we have the following "high-level" construct of
> data (required for push):
>
> - PushApplication ("HR Mobile")
> - MobileApplication ("HR for iPhone", "HR for iPad", "HR for Android")
> - Installation ("Matthias uses iPhone HR", "Matthias uses Android HR",
> "Bruno uses iPad HR")
>
> (More details here <https://gist.github.com/matzew/6012edf62d1915689a67>)
> <https://gist.github.com/matzew/04346e212e317d976532#data-per-installation...>Data
> per installation per device
>
> Now, thinking about what to store for an actual device gives you lot's of
> choices. For instance, Helios/Orbiter stores a lot of information in the
> "device" database (e.g. (current) Location Data, Locale etc).
>
> Like you can see here:
>
> [image: Helios Web UI Screenshot]<https://raw.github.com/helios-framework/helios.io/assets/helios-screensho...>
>
> All the information is really app specific (e.g. not every app needs to
> know the current location...); (A side-note... our client SDK should be
> flexible to store what ever the application requires...)
> <https://gist.github.com/matzew/04346e212e317d976532#mandatory-data>Mandatory
> Data
>
> Regardless of what data is desired or not, the following is the minimum
> that needs to be stored:
>
> - Device Token (generated by the PushNetwork (e.g. APNs, GCM) - used
> to identify the device with the actual Network, so that it can send a
> message to that device)
> - OS and Device Type (we need to store if this is an installation of
> the iPad version, the iPhone version or the Android version (to use the
> above HR example))
> - OS Version (the version, never hurts)
>
> This is the minimum of data, required to store in our "device
> registration" database;
>
> As discussed in AEROGEAR-1101<https://issues.jboss.org/browse/AEROGEAR-1101>,
> I would like to store the above "device" data, using the Picketlink IDM
> (Actually the entire data base (PushApplication, MobileApplication and
> Installation("device")).
> <https://gist.github.com/matzew/04346e212e317d976532#user-data->User
> Data ?
>
> Now... you might wonder if there isn't any user data required ..... Well,
> that is also up to the application and how works.
>
> Overall, I see the following two common application models, suppored by
> the *Push Server*:
>
> - device has a user (a known user in an Application (e.g. Marketing)
> Databases)
> - device has *NO* user (no need to have a user for the app)
>
> <https://gist.github.com/matzew/04346e212e317d976532#user-required>User
> required
>
> This would be an app, that requires an account, before it can be used on
> the device (e.g. something twitter). For applications like that, a user is
> required, otherwise hard to send a Push Notification to a specific user
> (e.g. "You have new tweets") ( *Also twitter works only with a user, on
> their "application backend/database"* )
> <https://gist.github.com/matzew/04346e212e317d976532#no-user-concept-on-th...>No
> User concept, on the backend
>
> That's a (very) simple app. Think *Sports App*. The app displays "sport
> news" (fetched via HTTP, when the app is opened). A installed application
> can also receive "broadcasts messages".
>
> *Scenario:* You download the app in the app store, install it, use it;
> When ever the backend thinks it needs to send Notifications (eg. "New score
> 3:1 at Germany - Brazil"), it simply uses the token and submits the message
> to the actual Push Network. For applications like this, the backend does
> not need a user;
> <https://gist.github.com/matzew/04346e212e317d976532#application-with-user...>Application
> with User required
>
> Now, let's comeback to the apps, where a user is required, in the backend.
> Somehow the business backend (e.g. HR system) needs to identify a certain
> user (and their devices), so that it can "submit" Push Notification jobs.
>
> Bruno, Shane (from Picketlink) and I talked already to store something
> like a unique ID (e.g. user-id, login-name or user-name) in the "Device"
> Table (per device):
>
> TOKEN | user | DEVICE-TYPE | OS-VERSION
> _________________________________________________________________________
> 823ssar | abstractj | Android | Android4.x.y.blah
> 1234456 | mwessend | iPad | iOS4.0.1
> ghh2712 | mwessend | iPhone | iOS6.1.2
>
> Doing so, we can use that "unique ID" to *bridge* between the actual
> "application database" and the stored informations about the device(s),
> stored in the *push-server-database*; per user!
>
> *NOTE* Since the Push Server (and the "device database") is a standalone
> server (access via HTTP / Java Library), the real (business) backend (e.g.
> HR App), can than say:
>
> *Send message X to to following users* (a list of unique user IDs would
> be send to the push server, so that the Push Server submit these messages
> to the actual Push-Networks (ANPs/GCM)so that Apple and Google (for
> iOS/Android) can deliver the actual notification to the client/device.
> <https://gist.github.com/matzew/04346e212e317d976532#client-sdk>Client
> SDK
>
> Again, As said above, we should (and will) offer hooks to have a
> convenient way to register the unique ID, together with the
> token,OS,version etc. *BUT* *that is not that important here... ;-)*
>
> *
> *
>
> *Thoughts?*
>
> *
> *
>
> *
> *
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 11 months
What is it about
by ashish
Hi,
We are building an application using JBoss middleware. This application has
a web based front end. We are thinking of extending this web application's
reach to mobile devices (iOS and Android). I came across the AeroGear
project and have some questions.
1. What is AeroGear about? How can it help someone in my situation?
2. Why would someone not build a native application (using Objective-C for
example) and invoke a web service made available via our server side
application? Where does AeroGear fit?
3. I read about hybrid mobile app development tools so how does AeroGear
relates to things like PhoneGap, JQueryMobile and Apache Cordova.
Thank you
Ashish
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/What-is-it-about-tp2327.html
Sent from the aerogear-dev mailing list archive at Nabble.com.
12 years, 11 months
Security Scaffolding
by Sebastien Blanc
Good Morning !
I've been thinking about Security Scaffolding. It's a different beast than
a simple CRUD scaffolding. It'sa bit more difficult to make assumption
when you want to generate security flows : which http method to protect ?
using only authentification or also authorization ? etc ...
Therefore, I've been thinking of some kind of configuration that the user
could provide before the scaffolding process. Keeping it really simple and
"human readable" and that could really speed up setting up the security
layer :
{
"security":
"createUsers" :["sebi","abtractj"], //1
"createRole" :["simple","admin"], //2
"roleMap": ["simple":["abstractj","sebi"],"admin":["sebi"]], //3
"generateLoginForm" : true, //4
"generateOTPPage" : true, //5
"entities" : { //6
"org.sebi.Task" : {
"GET": {
"authentification" : false
},
"POST": {
"authentification" : true,
"authorization" : "simple"
},
"PUT": {
"authentification" : true,
"authorization" : "admin"
},
"DELETE": {
"authentification" : true,
"authorization" : "admin"
}
}
}
}
Let me detail each of these points to make the discussion easier :
* 1. createUSers : We pass a list of users that we be inserted into
the db : this will generate or a SQL script or a class creating the
users like in https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...
* 2. createAdmin : We pass a list of roles that we be inserted into
the db : this will generate or a SQL script or a class creating the
users like in https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...
* 3. roleMap : We create here an association map between users and
roles : this will generate or a SQL script or a class creating the
users like in https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...
<https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main...>
* 4. generateLoginForm : if true, the UI scaffolding will also
generate a login form (location and layout depending on the
scaffolding provider (AngularJS+Bootstrap, AngularJS+JQM) or by
providing a custom template fragment.
* 5. generateOTPPage : if true, the UI scaffolding will also generate
a OTP page (location and layout depending on the scaffolding provider
(AngularJS+Bootstrap, AngularJS+JQM) or by providing a custom template
fragment.
* 6. Entities : Here we configure the security flow for each entity
per HTTP methods. Concretely, this will mean :
- On the backend, generate the right route, i.e :
route().from("/task").roles("admin"*)*.on(RequestMethod.DELETE).to(Task.class).delete();
- On the frontend, setting the flag or not on a pipe to enable auth. Other
option are possible, liking hiding links, disabling button depending on the
authorization/authnetification. We should discuss these options.
I think it could be a nice addition, and from the feedback I've heard, this
kind of feature really misses today in the current scaffolding tools
regarding security. This could be really a killing feature and not hard to
implement.
Please comment, ask questions to polish the feature !
Seb
12 years, 11 months
Towtruck
by Kris Borchers
Probably another source of research/inspiration for data sync that I plan to look into.
12 years, 11 months
Convention when passing baseURL, endpoints, id, resources ...
by Sebastien Blanc
Hi,
Today when we set up a Pipe and call methods on it, we have a different
ways on how we can pass the stuff which are part of the URI and more
particularly the leading or ending "/" :
```
baseURL: "http://www.slackers.com" //no ending slash
endpoint: "/security" //we have to start with a slash
```
But we can also do it the otherr way around :
```
baseURL: "http://www.slackers.com/" //ending slash
endpoint: "security" //no starting slash
```
Both are valid because our library (at least JavaScript) don't do any
manipulation for ```baseURL``` and ```endpoint```.
But if you take the parameter ```id``` on the ```read``` function, this one
must not have a leading "/" because it's added by the library:
```
id: "team1" //works
id: "/team" //fails
```
Until now ```id``` was the last part of the URI but since we are planning
to add nested resources, ```id``` won't be necessarily the last fragment.
For example, we could have a new parameter called ```resource``` to be
appended at the end :
```
baseURL = "http://www.slackers.com/" //ending slash
endpoint: "security" // no starting slash
id: "5" // handled by lib
resource: "/crypto" //leading slash needed
```
As the spirit of Pipes (at least for REST) is to offer an abstraction
around the Ajax and URL handling plumbing code, I think we should have a
convention for passing URI fragments that is the same for all. My
suggestion is to do the same as for ```id``` : no leading ``` / ``` or
ending ``` / ```.
If the user passes a leading or ending ``` / ```, the library will removed
it because it will be added implicitly. This way we are safe.
Remarks ? Questions ?
Seb
12 years, 11 months
AeroGear Connectivity
by Matthias Wessendorf
AeroGear Connectivity
The connectivity part in AeroGear (name: *AeroGear Connectivity Server*?)
is responsible to deliver messages from the server to the client. It
contains two *different* components:
- Device Push
- Web Push
The *Web Push* offers a low-latency message deliver from the server to *
connected* clients, while the *Device Push* delivers notification-style
messages to an explict application, deployed on a mobile device.
<https://gist.github.com/matzew/17f793e4be11473423d2#device-push>Device Push
Push Notifications can be send to an explicit application (or even a
specific installation), deployed on a mobile device, wheter the application
is running or not. Push Messages are *not* intented to deliver large
messages, nor in a low-latency fashion. They are more notification-style
messages. The latency can not be controlled, since the actual message
delivery, to the phone, is controlled by the actual *Push Network*.
The AeroGear server submits messages, for a certain mobile app, to such a *Push
Network* (like APNs or GCM). Different*Push Networks* have different
limitations and restrictions, regarding message size, etc. Most *Push
Networks* queue the message for offline devices (e.g. no connection, no
roaming or device switched off). Once they are back online the message are
delivered. Since these messages can become *stale* the *Push Network* allow
to specify an expiry time.
<https://gist.github.com/matzew/17f793e4be11473423d2#supported-client-plat...>Supported
client platforms
Initially we are supporting the following platforms:
- Android
- iOS
*Note*: The above platforms includes hybrid containers, such as Apache
Cordova!
In the future we may add support for more platforms, such as:
- Firefox OS
- Blackberry
- Windows
*NOTE*: One thing to have in mind, that there will be (eventually) a JS
API, which allows a server to deliver messages to a JS application,
deployed on any phone. *However*, it may take very long to get a unified
standard, that works accross the different devices. Platforms like Firefox
OS address this already, but only for one specific device type
<https://gist.github.com/matzew/17f793e4be11473423d2#web-push>Web Push
The *Web Push* allows a low-latency message exchange between *connected*
(read: *online*) clients and the server. This is usually realized with
technologies like WebSocket (or robust fallbacks like SockJS). Once a
client application connects, it can exchange (receive and send) messages
with the server (and other clients). Messages have no restrictions in terms
of size of content (JSON, binary). While technoques like SockJS
provide a *socket
connection* between the client and the server, it is desired to have a more
high-level API, to be used for the communication (e.g. Stomp).
Initially, Clients that are offline are *NOT* receiving messages. Messages
are not persisted and stored, to be delivered later.
<https://gist.github.com/matzew/17f793e4be11473423d2#supported-client-plat...>Supported
client platforms
- Android (Java client library)
- iOS (ObjC client library)
- JavaScript (JS client library, to be used in browsers and hybrid
containers)
Thoughts? The original gist is store here:
https://gist.github.com/matzew/17f793e4be11473423d2
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 11 months
Collecting Data - Client SDK for push registration
by Matthias Wessendorf
Hello,
I took a look at the Helios server (
https://github.com/helios-framework/helios).
It is a Sinatra based "Web UI", on-top of a PostgreSQL Database, which has
a RESTful endpoint to accept device registration information/data;
On the (iOS) client, they recommend the usage of the Orbiter client
framework (a simple wrapper around AFNetworking);
I am not planing to use the Orbiter client framework, but just to layout
the level of data which, MAY be stored for a registered "application
installation" on a device
It has nice hooks to provide a "quite time", for disabling message delivery
in a certain time interval:
https://github.com/mattt/Orbiter/blob/master/Orbiter/Orbiter.h#L86-87
However, the framework collects a lot of other data as well :)
For instance... it collects location data (if enabled, on the device), but
the API doesn't really tell you that - it's collected by the implementation:
https://github.com/mattt/Orbiter/blob/master/Orbiter/Orbiter.m#L100-101
So I was surprised to see that in the JSON response :-)
Sure... it's useful - for some apps - but I think... If we want to allow
our uses to store that kind of data, we should:
- add API hooks (into the client SDK) - may become 'verbose'... after a
while
- show how to do that and use a generic API (e.g. NSDictionary)
At a low-level, we really "just" require the device token and the
version/variant of the os (e.g. iOS 6.1.3). Any other data is APP specific
and really needs to be defined by the application developer that is using
our bits.
Any thoughts ?
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 11 months
