AeroGear Crypto Java 0.1.2 released
by Bruno Oliveira
Good morning, just to let you know we released today the bits for digital signatures and some bug fixes.
Have a happy new year sweet hearts.
--
abstractj
4 years
[UPS] Proposal to change the Push Message Format
by Sebastien Blanc
Hi,
I was looking at our current Push Message Format[1] and I was wonderimg if
you should not add some more structure to it, decoupling config, criterias
and the message itself :
{
"config" : {
"ttl" : 3600,
"content-available" : true,
"simple-push": "version=123"
},
"criteria" : {
"alias" : ["user(a)account.com", "someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737"]
}
,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"someKey":"some value",
"anotherCustomKey":"some other value"
},
}
wdyt ?
Sebi
[1]http://aerogear.org/docs/specs/aerogear-push-messages/
11 years, 7 months
Differences between Firefox OS "native" Push lib and AeroGear's Push adapter
by Sebastien Blanc
Hi,
While playing today with my Firefox Device and its native Simple Push
support I noticed some differences between our implementation and the
native Push regarding the success callback after a register :
//Native FFOS Push
broadcastRequest = navigator.push.register();
broadcastRequest.onsuccess = function (event) {
broadcastEndpoint = broadcastRequest.result; // only contains the pushURL
}
//Aerogear Push Adapter
broadcastRequest = navigator.push.register();
broadcastRequest.onsuccess = function (event) {
broadcastEndpoint = broadcastRequest.result.pushEndpoint;
channelID = broadcastRequest.result.channelID;
version = broadcastRequest.result.version;
status = broadcastRequest.result.status
}
So, the AeroGear Push exposes much more in the callback that it should
suppose to do : just exposing the pushEndpoint.
The reason we do that I suppose, but Luke or Kris could confirm that, is
that we thought respecting the SPS protocol, which indeed returns a whole
object containing all the info. It is just that the Native Push Client API
filter that out in the callback response.
After discussing that on the #push channel with the Mozilla people they
confirmed me that we should only expoe the pushEndpoint.
If we keep it as is, this can be problematic when we want to use the same
code both for native and with the adapter when, for instance, registering
to the UPS :
broadcastRequest = navigator.push.register();
broadcastRequest.onsuccess = function (event) {
broadcastEndpoint = event.target.result;
var broadCastSettings = {
metadata: {
deviceToken: broadcastEndpoint.channelID,
simplePushEndpoint: broadcastEndpoint.pushEndpoint
}
}
UPClient.registerWithPushServer(broadCastSettings);
}
This won't work with the native push since "broadcastEndpoint.channelID"
will be undefined.
So I propose that we change the behaviour, to return only the pushEndpoint
in the callback, even if that means a bit of String manipulation when we
want to perform the registration to the UPS :
var broadCastSettings = {
metadata: {
deviceToken:
broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1),
simplePushEndpoint: broadcastEndpoint
}
}
wdyt ?
Seb
ps : our SPS Server implementation stays correct and returns what should be
returned, it's really just the client part and how we expose the result
11 years, 10 months
Modularizing the Android Library
by Summers Pittman
Earlier in development (pre passos) making the Android SDK into modules
was not a concern (in fact it was an anti-concern).
Now, however, we have a much more complete project and it is time to
have that discussion.
Right now we have two BIG questions:
1) Do we want to break out interfaces and implementation?
If we do this then we could reuse a lot of code to make a aerogear-java
as well.
2) How granular do we want our modules?
IE If we break out push into aerogear-android-push would that include
GCM, SimplePush, MQTT, etc in one package or would it look like
aerogear-android-push-core, aerogear-android-push-mqtt etc.
Thoughts?
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
11 years, 10 months
Issues with Aerogear on Cordova
by Miguel Lemos
Hello,
I'm still struggling, for saying the least, with Aerogear documentation in
order to make a Cordova / Android app receive push notifications.
Amazingly one of the most unexpected issues has been with the correct
string to use on URLs to register or sending the notifications.
Examples given by documentation:
Openshift:
curl -u "{PushApplicationID}:{MasterSecret}"
-v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
"someKey":"someValue",
"alert":"HELLO!",
"sound":"default",
"badge":7,
"simple-push":"version=123"
}'
http://SERVER:PORT/CONTEXT/rest/sender/broadcast
Aerogear:
curl -3 -u "{pushApplicationID}:{masterSecret}"
-v -H "Accept: application/json" -H "Content-type: application/json"
-X POST -d '{"message": {"alert":"AeroGear UnifiedPush and Apache
Cordova 3.0.6", "badge":1}}'
https://SERVER:PORT/CONTEXT/rest/sender
How the above examples, apparently mean that, in my case, I must use
something like: https://aerogear-metalpush.rhcloud.com/rest/sender
maybe is very obvious for someone inside Aerogear lingo, but not at all for
me...
Anyway, after I managed to overcome this, the answer I get from the server
is this one (stripped from more irrelevant parts):
> POST /rest/sender HTTP/1.1
> Authorization: Basic
MDBhMjFjZTMtYTdkOS00YzhjLWI1ODMtOWYwMjEwYTYzNGU1Ojk0MTE4NmIzLWVjNmEtNGY0OC1iMjZiLTJkMDYxZWIyM2Q5Yg==
> User-Agent: curl/7.30.0
> Host: aerogear-metalpush.rhcloud.com
> Accept: application/json
> Content-type: application/json
> Content-Length: 50
>
} [data not shown]
* upload completely sent off: 50 out of 50 bytes
< HTTP/1.1 200 OK
< Date: Tue, 18 Feb 2014 20:58:18 GMT
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Content-Type: application/json
< Content-Length: 13
< Vary: Accept-Encoding
<
{ [data not shown]
100 63 100 13 100 50 11 44 0:00:01 0:00:01 --:--:--
44Job submitted
* Connection #0 to host aerogear-metalpush.rhcloud.com left intact
As far as I can guess, this means that the request was accepted.
Nevertheless, I receive nothing on the client's side.
On my phone the successHandler function throws a success message, meaning
that the equipment has managed to register at the service.
And my code to receive the notifications is the same given in some examples:
function onNotification(e) {
alert(e.alert);
)
But nothing happens, tough. Thanks for giving me some clues to solve this.
Miguel
11 years, 10 months
contacts-mobile-basic quick start
by Erik Jan de Wit
Hi,
I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to.
Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can’t pretend to send a message like someone else.
What do you think?
Cheers,
Erik Jan
11 years, 11 months
[QUICKSTART] Information for the mobile clients
by Sebastien Blanc
Hi all,
As we are almost done with the HelloWorlds, I think we can we start on the
Quickstart clients. As a reminder, the Quickstart will consist in a simple
Contact CRUD application with the possibility to send a Push Notification
to one of the listed contacts. Please refer to this
JIRA<https://issues.jboss.org/browse/AGPUSH-604> to
have more information.
The clients will have to communicate against secured REST endpoints. Joshua
and Pedro have started to work on that but nothing official is released
yet. I've tried out their
branch<https://github.com/pedroigor/jboss-wfk-quickstarts/tree/PLINK-392/contact...>
and
IMHO it's good enough to start using it for building our clients, the
restpoints won't change that much I believe.
And because I love you, I deployed on OpenShift a version of this secured
backend to ease the development of the clients !
If you browse to http://contacts-sblanc.rhcloud.com/ you will even see the
mobile web client. This deployed version contains also the Push Message
endpoint.
The branch of this deployed version can be found
here<https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_sec...>
.
But let's take a look at the diffrent REST endpoints :
<https://gist.github.com/sebastienblanc/10966803#crud-operations>CRUD
operations
I won't detail them here, since there is already a doc for that :
https://github.com/jboss-developer/jboss-wfk-quickstarts/blob/2.6.x-devel...
<https://gist.github.com/sebastienblanc/10966803#security>Security
*DISCLAIMER* : These might change
<https://gist.github.com/sebastienblanc/10966803#register>REGISTER<https://gist.github.com/sebastienblanc/10966803#register-a-new-user>register
a new user<https://gist.github.com/sebastienblanc/10966803#restsecurityregistration>
/rest/security/registration
- Request type: POST
- Request type: JSON
- Return type: JSON
- Request example:
curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H
"Content-type: application/json" -X POST -d
'{"firstName":"Jaime","lastName":"Lannister","userName":"jaime.lannister(a)westerlands.com","password":"hearmeroar"}'
http://contacts-sblanc.rhcloud.com/rest/security/registration
*NOTE* : We should use the convention to use the *email* as userName
<https://gist.github.com/sebastienblanc/10966803#getlogin>GET/LOGIN<https://gist.github.com/sebastienblanc/10966803#rerieve-a-user-and-log-hi...>Rerieve
a user and log him
in<https://gist.github.com/sebastienblanc/10966803#restsecurityuserinfo>
/rest/security/user/info
- Request type: GET
- Request type: JSON
- Auth : Basic Auth
- Return type: JSON
- Request example:
curl -v -b cookies.txt -c cookies.txt -u
"jaime.lannister@westerlands.com:hearmeroar" -H "Accept:
application/json" -H "Content-type: application/json" -X GET
http://contacts-sblanc.rhcloud.com/rest/security/user/info
<https://gist.github.com/sebastienblanc/10966803#logout>LOGOUT<https://gist.github.com/sebastienblanc/10966803#logout-a-user>Logout
a user<https://gist.github.com/sebastienblanc/10966803#restsecurityuserinfo-1>
/rest/security/user/info
- Request type: POST
- Request type: JSON
- Return type: JSON
- Request example:
curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H
"Content-type: application/json" -X POST
http://contacts-sblanc.rhcloud.com/rest/security/logout
<https://gist.github.com/sebastienblanc/10966803#push-rest-endpoint>Push
Rest Endpoint
I've added a new endpoint to push a message. In the deployed version, it's
hardcoded for now to send to the "quickstart" application created for the
https://quickstartsups-sblanc.rhcloud.com/ UPS instance, you will also have
to create the appropriate variants.
<https://gist.github.com/sebastienblanc/10966803#registration-with-the-ups...>Registration
with the UPS instance
I think the good flow would be to register with UPS once the login was
successfull. As *alias* the *email*should be passed
<https://gist.github.com/sebastienblanc/10966803#endpoint>Endpoint<https://gist.github.com/sebastienblanc/10966803#restcontactssendmessage>
/rest/contacts/sendMessage
- Request type: POST
- Request type: JSON
- Return type: JSON
- Request example:
curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H
"Content-type: application/json" -X POST -d
'{"author":"Jaime","receiver":"john.snow(a)thenorth.com","message":"Winter
is coming !"}' http://contacts-sblanc.rhcloud.com/rest/contacts/sendMessage
So here we can see that we pass data like :
{
"author":"jaime.lannister(a)westerlands.com",
"receiver":"john.snow(a)thenorth.com",
"message":"Winter is coming !"
}
To keep it simple, the client should always pass a hardcoded value for the
message , we don't want (for now)to add any complexity to the clients by
adding an extra dialog to enter custom messages.
author and receiver should contain the emails as we used that for the alias in
UPS.
So, I hope all this will help to boostrap the client's work. Remarks,
questions ?
(the content of this email is available
here<https://gist.github.com/sebastienblanc/10966803>
)
Sebi
11 years, 11 months
