Mutable vs Immutable for AGMemoryStore and AGPropertyStore
by Corinne Krych
Hello Guys,
Using AGPropertyListStorage in Xmas app [1], 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.
What happened?
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 [2].
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
Options
- 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.
++
Corinne
[1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
[2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
9 years, 10 months
Website restructure
by Hylke Bons
Hey everyone,
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
quickly.
https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
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).
1. Naming
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.
2. Documentation
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
AeroGear API.
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.
Missing pieces:
- 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.
Thanks,
Hylke
9 years, 10 months
OAuth2 Adapter
by Lucas Holmquist
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.
Thoughts?
9 years, 11 months
[aerogear-android] Skip SQLStoreTest when running on OSX and Java 1.7
by Tadeas Kriz
Hey,
I’ve been investigating the issue with SQLStore testing through Robolectric and this is what I’ve found.
Those tests run correctly on linux with both Java 1.6 and Java 1.7 and also works on Mac OS X with Java 1.6. This unfortunately doesn’t apply for the Java 1.7 on Mac and the test is failing. And because I think that this test should definitely not be @Ignore-d all the time, I’ve come up with following solution.
In JUnit, there’s a way to decide whether to run a test or not in runtime, based on org.junit.Assume. This way, we could easily ignore the SQLStoreTest when running on Mac OS X with Java 1.7, but leave it on other platforms. I’ve already taken the liberty to write this down and I’ve bundled it into the PR [1] which is fixing the doubly-called Callback#onSuccess bug (AGDROID-150).
What do you guys think about this solution, or should I say workaround? Of course it’s not perfect, it would be cool if we could run even the SQLStoreTest on all platforms without any difference, but right now it seems to be a incompatibility of SQLite with Mac’s Java 1.7.
1 - https://github.com/aerogear/aerogear-android/pull/120
—
Tadeas Kriz
tkriz(a)redhat.com
10 years
Safari & Chrome Push Support in UPS, release planning.
by Sebastien Blanc
Hi,
We have currently some items open to support Push on Safari & Chrome
Package Apps [1].
According to the Road map, this should be delivered for the 0.11.0 release
but since Luke is faster than Flash, the PRs for the Chrome Package Apps
have already been submitted.
I would like to suggest to deliver the chrome bits for the 0.10.0 release
and keep the Safari bits for the 0.11.0 release.
wdyt ?
Seb
[1] https://issues.jboss.org/browse/AGPUSH-453
10 years
AeroGear JS Crypto questions/findings
by Apostolos Emmanouilidis
Hi,
While reading and testing the AeroGear JS crypto library, I came up with
some questions/findings. Before opening JIRAs I'd like to discuss them
with you.
a) The KeyPair function which creates a pair of cryptographic keys for
assymetric encryption is using the SJCL ECC library [1] to generate keys
if no keys are provided.
sjcl.ecc.elGamal.generateKeys( 192,0 )
If I understand well, the first argument (192) is the elliptic curve
and the second argument (0) is the paranoia. These values are hardcoded
inside aerogear.crypto.js. Is there any specific reason for which the
values are 192 and 0? According the BSI recommendations [3] and NSA
suite cryptography sheet [2]], the elliptic curve is recommended to be
256 for secret level or 384 for top secret. The SJCL source code shows
that if paranoia is set to be 0 then the random value generator [7] is
called with paranoia value 0 and the consequence is that the SCJL
randomWords is called with paranoia value 0. According the SCJL author's
comments [6], calling the randomWords with paranoia value 0 is
explicitly warned against, and is for use only in unit tests where
entropy may not be available. Maybe we should consider increasing the
elliptic curve and paranoia values or allow the user to set his desired
values by passing them when creating the keys. The same applies for
digital signatures support ECDSA [8].
Below you can see some performance results for
sjcl.ecc.elGamal.generateKeys(elliptic curve). Unfortunately I'm facing
issues when trying to measure the performance on Safari and Chrome
browsers. If I manage to resolve them, I'll let you know their
performance statistics.
b) The getRandomValue method [4] which creates cryptographically pseudo
random values is using the window.crypto.getRandomValues of the
WebCryptoAPI [9]. The browser compatibility map for this method,
according [5] is:
Regarding the Android browser support, the crypto.getRandomValue is
supported in Android versions >= 4.0. In previous Android versions, I
receive an exception on line aerogear.crypto.js line 86. This means that
the crypto.getRandomValue is not supported in Android versions < 4.0.
Shouldn't we add a check to verify whether WebCryptoAPI is supported on
the browser? Something like if (window.crypto &&
window.crypto.getRandomValue) {....} else { //handle the case }. My
first thought is to use to SJCL random to produce cryptographically
pseudo-random values in the cases where the WebCryptoAPI is not
supported by the browser. There are some vulnerabilities [6] if SJCL
randomWords is called without calling startCollectors() to start the
entropy collector on page load and paranoia is set to 0. SJCL
startCollectors() needs to be called on page load so that entropy
collector is started and the random values produced from SJCL are
strong. To be honest this solution seems to me as quite dirty. Should we
add an alternative pseudo-random values generator in the cases where the
WebCryptoAPI is not supported by the browser?
[1]:
https://github.com/aerogear/aerogear-js/blob/master/src/crypto/aerogear.c...
[2]: http://www.keylength.com/en/6/
[3]: http://www.keylength.com/en/8/
[4]:
https://github.com/aerogear/aerogear-js/blob/master/src/crypto/aerogear.c...
[5]:
https://developer.mozilla.org/en-US/docs/Web/API/window.crypto.getRandomV...
[6]: https://github.com/bitwiseshiftleft/sjcl/issues/77
[7]:
https://github.com/bitwiseshiftleft/sjcl/blob/master/core/ecc.js#L385
[8]:
https://github.com/aerogear/aerogear-js/blob/master/src/crypto/aerogear.c...
[9]:
http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130625/#RandomSource-method-g...
10 years
safari push
by Lucas Holmquist
so i started to play with Safari Push notifications, here is my experience:
Setup
like iOS, you need to login to the dev portal and create an application ID, in this case a website ID, then do all the same things with certifcates and such.
the next part is you need to create a "push package" that either resides on the server your "website/webapp" is on as a .zip, or created dynamically at runtime. more on this later
The push package contains some things that are ultimately signed with your create certificate.
here is a link for more detail on the push package pp link
The client and server
Safari 7 on Mavericks ships with some new API's for doing push.
the first:
window.safari.pushNotification.requestPermission(url, websitePushID, userInfo, callback);
*url - a https url to a webservice *websitePushID - website push ID created in the dev console *userInfo - just some metadata if you want *callback - yup, it's asynchronous
so when this call is made, safari will make a POST to an endpoint like this:
webServiceURL/version/pushPackages/websitePushID
this is where you would serve your push package with the application/zip content type header thing
if all goes well with the push package, safari will ask the user to allow notifications, if the user allows them, then a POST to this endpoint happens
webServiceURL/version/devices/deviceToken/registrations/websitePushID
and the "device token" is then returned in the callback from above
a DELETE sent to that same endpoint if a user removes permissions.( haven't tried this yet )
if any error happens during any of these calls, this endpoint is POST'ed to
webServiceURL/version/log
here is my repo that is running on openshift( the easist way to get https since safari doesn't like self signed certs )
https://github.com/lholmquist/safaripush
the hardest part of this whole things is the actual setup of the push package
here is a repo i found that helped a bit, and apple also has a file that tries to help
https://github.com/connorlacombe/Safari-Push-Notifications
yes, i know, php.
i'm in the process of writing a node version, and yes, i've seen this one https://npmjs.org/package/web-push-package
UPS
So the good news is that the developer has to do all that stuff before they interact with the UPS.
Safari uses APNs( production only gateway ), but the payload is slightly different.
{
"aps": {
"alert": {
"title": "Flight A998 Now Boarding",
"body": "Boarding has begun for Flight A998.",
"action": "View"
},
"url-args": ["boarding", "A998"]
}
}
title and body are required
i sent a PR to get this updated in the java_apns thing https://github.com/notnoop/java-apns/pull/135
so we'll see what happens there
there is a lot of duplication in the UPS for the APN's stuff, i just wanted to get things to work first, but iOS and Safari share almost everything.
So maybe we need a more general APNs variant/sender whatever. i'm javascript dude, so my java skills are a bit rusty
i have a branch of the UPS where i am playing with this here https://github.com/lholmquist/aerogear-unified-push-server/tree/safaripush
the update UI is here https://github.com/lholmquist/aerogear-unified-push-server-admin-ui/tree/...
the modified java_apns is here
https://github.com/lholmquist/java-apns/tree/safari_push
there might be things missing, i'm just trying to download my brain
10 years
