Push Endpoints
by Lucas Holmquist
I've been looking at the endpoints of the push server a little more since coding the Admin UI, and i see that for "updates" and "deletes", the response is "no content"
for example:
https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/...
I wasn't sure what we should be returning here.
I'd imagine for update we would want to return the update entity
but what about for delete? In the case of deleting a "Push Application", should we return the new list of Push Applications?
thoughts?
10 years, 5 months
Cookie Management APIs / Specs
by Summers Pittman
Y'all,
One of the open issues in Android today was to create a way to disable
the cookie store. After discussion, Passos and I decided to punt the
issue and expand it to create a Cookie API for the projects to follow.
The big issue with cookies on Android right now is they are global to
the application (A Java sdk/Android ism) and we don't provide a easy
facade or view into what is actually going on under the hood.
Before wandering off into the woods and making up some Android specific
nonsense we decided to get feedback from the community and try to make
some kind of spec. What should we provide, how should it look across
platforms, and what are the limitations of the platforms we have to
support? (I'm looking at you in browser java script)
Summers
10 years, 5 months
Android multipart cookbook component
by Summers Pittman
Y'all,
Passos and I were discussing making a cookbook component to demonstrate
using Multipart uploads in AGDROID. For most of our previous server
side components we've been using the ag-controller-demo project.
However, multipart isn't part of the controller.
Writing a simple one is easy (we already have plenty of things we could
use) but the problem is one of stability and security. IE we don't want
to make a file hosting service by mistake ;). My thought is to not
store any files but instead return a MD5 hash of the file uploaded and
to throw a 500 error on anything over 32k.
wdyt?
Summers
10 years, 5 months
JS Version Bump
by Kris Borchers
FYI, I just did an emergency patch release on AeroGear.js to 1.1.1. I broke `npm install` with my change to the jQuery dependency in our package.json. I have removed that dependency since it doesn't do us any good in there anyway because we don't package jQuery with our code.
Thanks
10 years, 5 months
Android PushConfig
by Summers Pittman
Good News everyone! We have code which registers Android devices to
receive messages from pushee.
It is still very VERY limited, but code which will display a
notification when the app receives a message looks like this:
https://gist.github.com/secondsun/242063868b09db030331
One of the reservations I've heard is whether or not the PushConfig
object should only have the data sent to pushee in it and put other
configuration elsewhere or if it should be the generic push
configuration object and let AG pick out what it needs to send to pushee.
By unifying into a single config object we make the code simpler/more
approachable. However if we slice it up a bit more finely we can
decouple pushee support from GCM if we want to have an AOSP flavor of
push messaging in the future.
wdyt?
PS and by pushee I mean aerogear-unified-push-server.
10 years, 5 months
HTTP_Basic: SimplePush (Channel) Registration
by Matthias Wessendorf
Hi,
with the use of this helper <https://github.com/davidchambers/Base64.js>,
it is "safe" (I think) to use the window.btoa function(see
details<https://developer.mozilla.org/en-US/docs/Web/API/window.btoa>),
to perform a (simple) Base64 encoding.
Base64 encoding is required, since the "Device Registration" HTTP REST
endpoint now uses HTTP_Basic (for details see the matching
thread<http://lists.jboss.org/pipermail/aerogear-dev/2013-June/003233.html>
).
Currently we perform this code for "channel registration":
$.ajax({
contentType: "application/json",
dataType: "json",
type: "POST",
url: url,
headers: {
"ag-mobile-variant": variantID
},
data: JSON.stringify({
category: messageType,
deviceToken: endpoint.channelID,
clientIdentifier: alias
})
});
As mentioned on the "Security thread", the variantID is no longer a header,
it is part of the HTTP_Basic auth process.
This is a (local) JavaScript change that I did. It works fine so far:
$.ajax({
contentType: "application/json",
dataType: "json",
type: "POST",
crossDomain: true,
url: url,
headers: {
"Authorization": "Basic " + window.btoa(variantID + ":" + secret)
},
data: JSON.stringify({
category: messageType,
deviceToken: endpoint.channelID,
alias: alias ///// NOTE:: the key has changed..........
})
});
The important thing: we add the "Authorization": "Basic " header and using
the mentionedwindow.btoa() function for the actual encoding.
The same applies for the DELETE (unregistration).
Any thoughts? Otherwise, I'd send a PR.
Ah.... the dependency agains the Base64.js polyfill library would/should be
included in our "grunt" build for "distribution", or would it be "just"
declared (yeah, that's details but asking for curiousity)
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 5 months
