Using AGPropertyListStorage in Xmas app , I run into this interesting issue:
In the app I retrieve a NSArray of NSMutableDictionary, I get a mutable copy of the NSArray and I save encrypted data in it.
I decrypt some of the data in memory BUT I actually don't want those to be saved decrypted into permanent storage.
And then let's say I add some more data with encrypted value then I save this dato to my AGProperListStorage. Just this one.
But surprise, if I look in my permenet storage, I see my newly data encrypted but the other data I ecrypted in memory were saved decrypted.
In one word: shallow mutable copy of NSArray.
My mutable array still point to original MSMutableDictionary and when saving one data to permanent storage the all memory is dumped into plist resulting in decrypted value to be stored.
How did I fixed it?
Using deep mutable copy see in .
In AGMemoryStorage (and its inherited AGPropertyListStorage) we use NSMutableDictionary because you can save item (represented as Key/Value with NSMutableDictionary) without id, the store will take care of generating this id and assign it back into the item.
Even the AGMemoryStorage which returns a NSArray of NSMutableDictionary is misleading because you can actually do
NSArray myArray = [store reallAll]
and then modify the contain of the memory storage without using save.
That experience brings the topic whether it's a good pratice to use mutable object
- option1: stick to immutable objects whithin the AGStore and let the save method return an immutable NSDictinary containing the item
- option2: leave it as it is, responsability of user to do deep copy
- others ?
Personal Preference go for option1 which I found less confusing.
Good morning peeps, yesterday I started to replace AeroGear Security on Unified Push server by Keycloak and you might be asking: “Why?”. Keycloak is a SSO with some handy features like TOTP, OAuth2, user management support and I think we have too much to contribute, is the only way to have some success with security, “divide to conquer" (at least for authorization and authentication).
So will ag-security be discontinued? No! Keycloak is still on Alpha and we have to test it against our projects before fully replace ag-security, but the only way to upstream our needs, is to using it.
This replacement only applies to authentication/authorization features, we still have a ton of projects which Keycloak is not able to replace like: TOTP, crypto and OAuth2 on mobile, our focus.
So let’s talk about this replacement, any dependency on ag-security was removed from the push server and replaced by Keycloak: https://github.com/abstractj/aerogear-unifiedpush-server/tree/o...
Based on Keycloak examples, I just did copy & paste from one of the demos (https://github.com/abstractj/auth-server/tree/openshift) to create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually replace some modules on JBoss.
To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be redirected to Keycloak, enter:
You must be redirected to agpush console, keep in mind that I took some shortcuts to get this demo working, so for example the create will fail because I removed everything related into the ember interface.
Is also possible to enable TOTP, user’s registration and whatever you want.
So what do you think?
So Jay asked me to look at how the website content is structured and how
to improve it. Since we have so much content, it gets confusing very
Here's a mockup of a possible solution. I'm better at explaining things
in pictures than in words, so please have a look. I'll explain things in
more detail below.
I've tried to keep every subproject use case based, and explain the use
case before features. See this as a bigger picture, and don't focus on
the graphic design too much, it's there to help explain the structure of
the project, and is not necessarilly a final graphical design in any way
(though if you like it we can make it work!), but I wanted to show how
different colour palettes can help explain the project and give a better
sense of where you are on the website.
I've done a lot of research on the project, but some things may be
wrong. So your feedback on that would be greatly appreciated. Even after
spending many months with the project, I still don't fully grasp
everything (which shows part of the problem).
I've split up the project into three main subprojects: "AeroGear Core",
"AeroGear Push", and "AeroGear Security". These three are the main focus
and use different icons and colour codings throughout the website to
guide people. Each subproject has "client" and "server" components.
Server pieces being appended by "Server Component" and may be standalone
or an addin to something. Client (API) pieces follow "Project.Namespace"
format. This way, there's never any confusion about what we're talking
about in the documentation and marketing materials.
Splitting up documentation. "documentation" can be a broad term. I
suggest splitting it up in three parts to easily find what you're
looking for: "Setting up" (downloading and boatstrapping a dev
environment), "Examples" (how to use the API in your environment to get
started), "API Documentation" (speaks for itself), and "Tutorials"
(setting up more complex environments and API usage). This covers most
of the documentation that is currently on aerogear.org and will make it
a lot easier to browse.
3. Coding languages
Where the API is unified across all platforms (hopefully most of it), we
can generalise example docs, and show a switcher for code blocks that
shows how to do a certain thing in a particular language using the
4. 1:1 mappings
I'd like to see the iOS, Android and Javscript APIs be self-contained
things that you can just drop in and use, with 1:1 mappings (what you
get on Android for a (sub)project, is what you get on iOS). There could
be technical reasons why these things are split up the way they are now,
let me know if so. I could be totally wrong on this too.
- Where do we fit in Cordova?
- AeroGear Auth, Controller?
These are things I'm not sure yet how they would fit in the proposed scheme.
I think this is a step in the right direction, and I really hope it is
helpful. Let's iterate on this. Let me know what you think and how we
can improve. Looking forward to hear your opinions on this.
We are planning on adding an OAuth2 adapter to the JS library for 1.3.0. We are going to code against the google OAuth2 playground stuff, but trying to follow the spec as much as possible and try to be as generic as we can.
I'm not sure if this should be an "adapter" or something different. If it is an adapter of the Authentication plugin( not sure what we are calling the different pieces. pipeline, data manager, etc.), then we should expect to see authentication methods( enroll, login, logout ), but i think this "adapter" should be much more than that.
It should be used to connect to secured services( api ) that a user allows, such as GCM for chrome or the google+ platform, or some other enterprisey thing.
I'm wondering if this should be a standalone thing. I kind of like this idea so when we do social login, which will most likely have OAuth2, we can just access it.