Best Strategy to do IDM with Custom User Model and AG Sec/PL
by Sebastien Blanc
Hi,
In my application model I have an User domain, quite specific to the domain
(it has specific attributes, relation with other model classes) : What is
the best way to link this user with the org.picketlink.idm.model.User ?
Should I subclass this User or decorate my own user class with PL stuff ?
Seb
12 years, 10 months
AeroGear UnifiedPush Registration Client Spec (DRAFT 0.0.3)
by Matthias Wessendorf
Hello,
following up on the previous drafts...
This document describes the functionality of a client SDK that works with
the AeroGear UnifiedPush
Server<http://aerogear.org/docs/specs/aerogear-server-push/>
.
<https://gist.github.com/matzew/569190db18694afe22f6#motivation--purpose>Motivation
/ Purpose
The AeroGear UnifiedPush
Server<http://aerogear.org/docs/specs/aerogear-server-push/> is
accessible via HTTP. Instead of having to manually register a device (
MobileVariantInstance) with the HTTP interface, a client library should be
offered.
*Goal:* A client library to register a mobile application (
MobileVariantInstance) with the UnifiedPush Server.
<https://gist.github.com/matzew/569190db18694afe22f6#background-push-netwo...>Background:
Push Network Token
To receive native push notifications from a Push Network (e.g. APNs, GCM or
SimplePush), the mobile device is identified with a unique device-token,
assigned by the actual Push Network. Thisdevice-token is passed, by the
underlying Operating-System, to the mobile application. Details are
different on each platform and *not* part of this document.
The device-token needs to be registered with the *AeroGear UnifiedPush
Server*, to indicate there is a new MobileVariantInstance for a
MobileVariant. More details about the server-side part of this can be found
in the *AeroGear Unified Push Server*
spec<http://aerogear.org/docs/specs/aerogear-server-push/>
.
<https://gist.github.com/matzew/569190db18694afe22f6#functionality>
Functionality
*WARNING:* *The focus of this specification is to describe the generic
minimum and not any platform-specific requirements*
The client SDK offers the following features:
- Registration and Updating of a MobileVariantInstance
- Unregistration of a Mobile Variant Instance (optional, due to platform
specific restrictions)
<https://gist.github.com/matzew/569190db18694afe22f6#registration-and-upda...>Registration
and Updating of a Mobile Variant Instance
Everytime when a mobile application launches it receives the above
mentioned device-token, via a*platform-specific* method (or callback).
Since the Push Network (e.g. APNs or GCM) *may* assign a *new*token to a
device, it is *recommended* to *always* (re)register the device-token with
the *AeroGear UnifiedPush Server*.
Besides the device-token the *AeroGear UnifiedPush Server* is able to store
some of the below device- or user-specific metadata:
- *deviceToken:* *Identifies the device/user-agent within its Push
Network.*
- *deviceType:* *The device type of the device or the user agent.*
- *mobileOperatingSystem:* *The name of the underlying Operating System.*
- *osVersion:* *The version of the used Operating System.*
- *alias:* _ Application specific alias to identify users with the
system. For instance an email addressor a username._
- *category:* *Used tp apply a "tag". Mainly usful for the SimplePush
channel(s).*
Besides the slight chance that the `device-token may change, some of the
above metadata is more likely to change. Therefore another reason to always
send this metadata to the *AeroGear UnifiedPush Server*.
<https://gist.github.com/matzew/569190db18694afe22f6#reachability>
Reachability
The client SDK needs to check if the device can establish a connection to
the internet (PushNetwork and UnifiedPush Server). It should make use of
the platform-specific APIs to check the reachablility of the services.
<https://gist.github.com/matzew/569190db18694afe22f6#unregistration-of-cli...>Unregistration
of client device information
*Optional* method that helps to unregister the client device information
with the AeroGear Unified Push
Server<http://aerogear.org/docs/specs/aerogear-server-push/>
. *Note:* *The method is optional, since not all supported Push Networks
recommend having a client application actively performing an _unregister*.
Apple for instance has a Feedback Service, which the*AeroGear Unified Push
Server* needs to freequently query for inactive tokens. Tokens, with Apple,
are*inactive* when the user:
- Disables Push (Settings)
- Deinstalls the app
<https://gist.github.com/matzew/569190db18694afe22f6#reachability-1>
Reachability
The client SDK needs to check if the device can establish a connection to
the internet (PushNetwork and UnifiedPush Server). It should make use of
the platform-specific APIs to check the reachablility of the services.
<https://gist.github.com/matzew/569190db18694afe22f6#authsecurity>
Auth/Security
To be discussed.....
<https://gist.github.com/matzew/569190db18694afe22f6#platform-specific-det...>Platform
specific details
Every client platform has it's own base APIs, to receive Push Message from
it's Push Network. The AeroGear client SDK *may* offer utilities to even
more simplify this process. *For example: In Android a custom Intent is
required, therefore it would make sense if the "AeroGear Android Push
Client Library" offers a convenience implementation for this class.*
*
*
BTW... Current, EARLY, implementations:
* JavaScript (to register SimplePush Variant Instance):
https://github.com/aerogear/aerogear-js/blob/Notifier/src/unified-push/ae...
* iOS (to register iOS Variant Instance):
https://github.com/matzew/ag-client-push-sdk
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 10 months
Forge plug-ins
by Deepali Khushraj
Could someone share a link to the current AG Forge plug-ins and docs please?
Thank you!
D.
12 years, 10 months
iOS testing - HTTP mocking
by Christos Vasilakis
Hi team,
for further improvements of our unit tests we have switched the http mocking mechanism we use (our own NSURLProtocol impl) to the popular OHHTTPStubs[1] project, a library currently recommended by the AFNetworking networking lib we use.
The basic mechanism is straightforward to use and encapsulated in one method:
return [OHHTTPStubsResponse responseWithData:data
statusCode:status
responseTime:responseTime
headers:headers];
in which a stubbed response is returned to the client.
Now, based on this mechanism, we have abstracted a bit and created methods such as:
+ (void)mockResponse:(NSData*)data;
+ (void)mockResponseStatus:(int)status;
+ (void)mockResponseTimeout:(NSData*)data status:(int)status responseTime:(NSTimeInterval)responseTime;
This gives the advantages that a) clearly indicate what http scenario we are testing and b) remove params that don't make sense for the particular scenario under testing e.g. that is we simulate a status of (404) but we need to pass all params eg. data, interval, timeout, etc. But this doesn't limit us, we can do that if we want and use the full blown method with all the params attached.
I have created two branches in my fork, one that uses a blocks approach inside the testing class [2] and one that the functionality is extracted in a helper class that the testing classes can use [3]. The second approach was created because there was common code and didn't want to duplicate it over the testing classes.
I would be interesting to know what is your comments on it?
Thanks,
Christos
[1] https://github.com/AliSoftware/OHHTTPStubs
[2] https://github.com/cvasilak/aerogear-ios/blob/ohhttpstubs/AeroGear-iOS/Ae...
[3] https://github.com/cvasilak/aerogear-ios/blob/ohhttpstubs.helper/AeroGear...
[4]
12 years, 10 months
AeroGear Security & Shiro
by Bruno Oliveira
Guess what? Is me again.
Good morning my friends, today was released on snapshots a version of
AeroGear Security Shiro
(https://github.com/abstractj/aerogear-security-shiro). If you want to
give it a try, please follow the instructions on README.
Common questions
- Are you planning to replace PicketLink?
No, no and no. PicketLink is our first class citizen on AeroGear.
- Why do we need support for Shiro on AeroGear?
Because is the benefit of freedom, people can choose their favorite
security provider.
- Are we end up with two implementations?
No, no and no. AeroGear Security just provide a DSL to make the
integration easy with these providers.
Issues, questions and feedback is always welcome.
--
abstractj
12 years, 10 months
