Security on AeroGear
by Bruno Oliveira
Good morning everyone, I'm planning to include JWS (to add digital
signatures per mobile application)/JWT (to issue a token at each
transaction or session) support on AeroGear and I was looking at OAuth2
bearer token (which make use of JWT/JWS behind the scenes)
implementation from RESTEasy.
I was reading about how to properly include it and now we have a
decision to make (we because it will affect the way the client side and
security is not an island :). RESTEasy bearer tokens is completely tied
to JBoss
(http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...)
and I'm not saying it is a bad thing, but with vert.x, TorqueBox,
Nodej...I'm not sure if it's a good idea.
An example of Bearer Token usage extracted from RFC
(http://tools.ietf.org/html/rfc6750)
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
Pros: RESTEasy team already did it
Cons: The configuration setup might be hard to newcomers (please look at
the documentation
http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...),
we will be tied to JBoss.
So, do we have an alternative? Yes. Make use of JWT module only from
RESTEasy and we still can benefit of digital signatures and tokens.
An example of JWT usage extracted from RFC
(http://tools.ietf.org/html/draft-jones-json-web-token-10#page-6)
{
"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true
}
Pros: Flexibility, we have people already doing it
(https://wiki.mozilla.org/WebAPI/WebPayment). We will make use of
RESTEasy module and do not reinvent the wheel.
Cons: The authorization model must be implemented and adapted to our needs
So what do you think?
ps: SAML is not an option for me now.
--
abstractj
13 years
AeroGear Unified Push Server
by Yavuz Selim YILMAZ
Hi all,
Is there any way to track errors on submitted push messages to the PushNetworks? Here is my scenario:
I have AG Unified Push Server deployed on my machine, and I created an application. Then I registered 2 iOS variants, one with my development certificate, and another with my distribution certificate (hope I did this step correctly, what I did was actually I run the iOS variant addition step for my both certificates - by following the steps here: https://github.com/aerogear/aerogear-unified-push-server). I am able to successfully register my apps with APNs (execution hits my corresponding delegate) and I am able to register my devices with client info to my AG Unified Push Server (registerWithClientInfo executes my success block).
But then, when I broadcast a message to everyone (using http://SERVER_IP:8080/ag-push/rest/sender/broadcast), my development device receives the notification while distribution device does not receive anything.
Is it because of the way I am creating the variants? Or a certificate issue that I couldn't track? Any thoughts or recommendations are appreciated.
Best regards,
---
Yavuz Selim Yilmaz
SUNY at Buffalo
Computer Science and Engineering
PhD Candidate
13 years
AeroGearPush iOS device registration error
by Yavuz Selim YILMAZ
Hi all,
After registering an application and iOS variant on my push server following the instructions on https://github.com/aerogear/aerogear-unified-push-server, I am implementing the following method on my iOS client:
// Here we need to register this "Mobile Variant Instance"
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
// we init our "Registration helper:
AGDeviceRegistration *registration =
// WARNING: make sure, you start JBoss with the -b 0.0.0.0 option, to bind on all interfaces
// from the iPhone, you can NOT use localhost :)
[[AGDeviceRegistration alloc] initWithServerURL:[NSURL URLWithString:@"http://10.193.23.8:8080/pushee/"]];
[registration registerWithClientInfo:^(id<AGClientDeviceInformation> clientInfo) {
// Use the Mobile Variant ID, from your register iOS Variant
//
// This ID was received when performing the HTTP-based registration
// with the PushEE server:
[clientInfo setMobileVariantID:@"MY_VARIANT_ID"];
// apply the token, to identify THIS device
[clientInfo setDeviceToken:deviceToken];
// --optional config--
// set some 'useful' hardware information params
UIDevice *currentDevice = [UIDevice currentDevice];
[clientInfo setOperatingSystem:[currentDevice systemName]];
[clientInfo setOsVersion:[currentDevice systemVersion]];
[clientInfo setDeviceType: [currentDevice model]];
} success:^() {
//
} failure:^(NSError *error) {
// did receive an HTTP error from the PushEE server ???
// Let's log it for now:
NSLog(@"PushEE registration Error: %@", error);
}];
}
The registerWithClientInfo call fails with this error:
PushEE registration Error: Error Domain=AFNetworkingErrorDomain Code=-1011 "Expected status code in (200-299), got 401" UserInfo=0x1d5522b0 {NSLocalizedRecoverySuggestion=Unauthorized Request, AFNetworkingOperationFailingURLRequestErrorKey=<NSMutableURLRequest http://10.193.23.8:8080/pushee/rest/registry/device>, NSErrorFailingURLKey=http://10.193.23.8:8080/pushee/rest/registry/device, NSLocalizedDescription=Expected status code in (200-299), got 401, AFNetworkingOperationFailingURLResponseErrorKey=<NSHTTPURLResponse: 0x1d549310>}
Do you have any idea/suggestion to solve my problem? Your help is appreciated.
Thanks and regards,
---
Yavuz Selim Yilmaz
SUNY at Buffalo
Computer Science and Engineering
PhD Candidate
13 years
JIRA: default assignment
by Matthias Wessendorf
Hi,
when someone creates a JIRA against AG-WHAT-NOT, these tickets have a
default assignee.
IMO this is bad.
That feels like: Someone did assign it to himself in order to work on it.
Which is not really true :)
Also, for growing a community: If a ticket (for e.g. low-hanging fruits) is
NOT assigned someone new will be more-likely go ahead and work on it, when
it is NOT assigned to someone.
So... I'd really vote for changing the "default assignee" to "not assigned"
Thoughts ?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
13 years
parent pom?
by Douglas Campos
While reviewing summers' PR I've found myself doing that tedious work of
fixing license headers again - what do y'all think part of our default
tools (like maven-license-plugin) on an aerogear parent pom (which
inherits from jboss parent pom, of course)
Thoughts?
--
qmx
13 years
Android AAR Project format
by Summers Pittman
Y'all,
pilhuhn asked on Twitter if we were planning to support the new aar
package format in AeroGear's Android library. Matzew suggested to take
it to the mailing list so I will run with it for now.
First an introduction. Aar is Google's new binary package format for
Android libraries. It is what their Gradle plugin looks for when it
fetches libraries. For those of you who havn't experienced the joy of
using Android Library Projects with Android Application projects this
fixes a whole host of maintainability and usability problems. Matzew
can probably explain the n00b experience better, but you should be
fluent in angry, angry German.
Now for the challenges. We use Maven to build AGDroid and the
maven-android-plugin does not yet support aar. Also in some Googling
last week I could find 0 documentation for the file format. Right now
the only way to make an aar build is to export an Eclipse Android
project and import it into Android Studio and let it build the aar for
you. This can then be packaged into maven central but is really labor
intensive.
Also the only thing which supports using aar is Android Studio /
Google's Gradle build stuff. Other than being on the cutting cutting
edge (and having a nice project feather in our cap) I don't really see
what this gets us right now.
With that said I would like to put energy toward this.
For now I propose we start building an aar as part of the release process.
Eventually I would like to lend a hand to the android-maven-plugin
project so they can export aars.
Right now I do NOT think we should look at porting the AGDroid source
project from maven to Android Studio.
Thoughts?
Summers
13 years
Push Server Admin UI packaging
by Lucas Holmquist
Currently i've started to develop the push server admin ui in a repo here:https://github.com/lholmquist/aerogear-unified-push-server-admin-ui ( be sure to look at the ember repo ;) )
my question is how should we package it with the push server. Should we keep developing the UI in a separate branch and then update the servers "web" directory with the "dist" directory( currently i'm using grunt to copy the non dist directory to the web directory of the server during development ) when we do a "release" of the admin UI,
or do we want to include all the unminified stuff in the "web" directory of the server.
-- There are 2 options here:
---- just develop in the push server repo
---- develop in a separate repo and then copy unminified stuff over
I kind of like the develop in a separate repo and copy over the dist directory for "releases" but in a read me or something, tell the developer how to modify the console if the want to
thoughts?
13 years
Android AAR Project format
by Heiko W.Rupp
Hey,
[ sorry for breaking the threading, as I have just subscribed. ]
I did not submit the build.gradle in order to replace the maven build,
but as an addition as this can just easily build .aar files. In addition
it is the default build format by Android Tools + Android Studio
While the new Android tooling still has some kinks, Gradle itself
is stable and e.g. (some part of) Hibernate is using it for some time now.
So I could imagine to just continue building as is and afterwards
running "gradle build" to also get an aar library build.
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
13 years
