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
2 years, 7 months
Chrome Push Messages
by Lucas Holmquist
Hello,
now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i’m starting to look at the new API that Chrome apps use for sending push notifications.
the TL;DR of it is, it’s basically the same as Android now.( no more refresh tokens and access tokens and such )
So the question is, do we need to have a deprecation period on what is currently there?
The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1
While i have looked to deeply, it’s possible we can use the same “Variant” structure for Chrome Apps, Since they will be using the same Network
wdyt?
-Luke
9 years, 10 months
[Android] KeyCloak Authenticator
by Summers Pittman
<tldr>DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC
AGAIN!</tldr>
Over the weekend I tried my hand at writing a Android Account
Authenticator for KeyCloak. This lets Android manage the KeyCloak
account, fetch tokens, provide tokens to other apps etc. KeyCloak
Authenticator let's you drop your keycloak.json file into an apk and
access your KeyCloak Account with one line of code from any application
on your Android device.
Right now this is very much in the "I have an itch needing scratching"
phase. It doesn't do any robust error handling, hasn't been testing off
the golden scenario, has no integration with any of the AeroGear stuff,
etc. Take a moment to watch the Demo and look at the demo project.
Video Demo :
https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
The Demo video uses Android's native account menu to request from the
authenticator a KeyCloak account. This launches the authenticator's
activity which will retrieve the credentials for Android and store
them. When I am back in the settings page and showing off the stored
account, this is all native Android UI and not part of the KeyCloak
authenticator.
When I launch the Demo application this is a separate application from
the authenticator apk. The Demo project fetches the KeyCloak account
from Android and gets its auth token. Then it makes a request to
KeyCloak's account service to fetch the user's account data.
In the demo app there are three lines of code related to auth.
final Account account = am.getAccountsByType("org.keycloak.Account")[0];
String token = am.getAuthToken(account, "org.keycloak.Account.token",
null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN);
and
provider.setDefaultHeader("Authorization", "bearer " + token);
The first two lines fetch the account and token from Android. The
second line attaches the account's auth token to the web request to the
server.
So now what? I'll probably use this for my projects/demos because it
makes my work easier. Right now it doesn't have any connection to any
of the "official" projects (Again, I wrote this over the weekend to see
if I could) however it may be quite useful to someone. In the project's
README I've included a (incomplete) list of things that don't work.
wdyt?
Links :
Project : https://github.com/secondsun/keycloak-android-authenticator
Video Demo :
https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
Demo Source :
https://github.com/secondsun/keycloak-account-authenticator-demo/
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
10 years
text/html Requests instead of application/json
by Marc Pires
Hi guys, i'm having a little trouble with an app i'm developing. Doing a
post request against an API, I receive from the server that my request is
going as text/html instead application/json, text/javascript or text/json
that the API expects.
As I never had this problem before, i research the docs but did not found
the reference yet, so how can i define my request to go as application/json
instead text/html
--
Desenvolvedor IOS, Rails, RIA
http://www.linkedin.com/in/marcpires
http://about.me/marcelo_pires
10 years, 1 month
message format change proposal
by Erik Jan de Wit
Hi,
With the upcoming windows support and simple push change (making simple push more like 'normal') the number of ‘special’ keys in our message is increasing. Right now we are mixing our ‘special’ keys with those the user can add, but we keep simple push out of it:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com", "someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"someKey":"some value",
"anotherCustomKey":"some other value"
},
"simple-push": "version=123”
}
As simple push is going to be more like ‘normal’ push why not move the simple-push into the message as well. As for the windows support there are a lot more types of messages you can send. The most normal form is called ‘toast’, but there are other ones for when you app is pinned to the home screen. Then one can send message that contain pictures. To support all of this we need something like this: https://gist.github.com/edewit/305d76c31960aa6254a9
Adding all these ‘special’ keys will make it easier to get into a conflict with the users own data, so I propose we put the user data into a separate data object, like so:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com", "someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"simple-push": "version=123",
"data" : {
"someKey":"some value",
"anotherCustomKey":"some other value"
}
}
}
WDYT?
Cheers,
Erik Jan
10 years, 2 months
[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/
10 years, 2 months
some cookbook recipes need some backend
by Corinne Krych
Hello Guys
To complete our cookbook repositories: iOS, web, android and cordova (still under eric private repo), I’d like to have a aerogear-backend-cookbook. We already have some demos which requires backend. I’ve put them together in:
https://github.com/corinnekrych/aerogear-backend-cookbook
Each app has a separate build and is independent. For new I’ve put together:
AeroDoc
PushQuickstart (as submodules)
Buddies
ProductInventory (oauth2 keycloak) kind of helloWorld app, very simple
Next addition, I’m thinking to do a Shoot’nShare file upload Server using Keycloak. So we can have a more complete demo of AeroGear OAuth2 and Keycloak.
Thoughts?
++
Corinne
10 years, 2 months
iOS meeting
by Corinne Krych
Hello Swifter and iOS lovers,
Here is the proposed agenda of our next meeting which will take place Tuesday 16 September at 2pm (CEST - UTC + 2hours)
soclap.com/p/aerogear_ios_meeting_11sept2014
Feel free to add topics to it and join us if you want to discuss with us next 2.0 iOS release.
++
Corinne
10 years, 2 months
