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.
Start point is this jira https://issues.jboss.org/browse/AGPUSH-282 for
allowing the creation of additional users/developers.
In the current situation we have just one role : "developer" , so the first
question is :
- Should a user with the role "developer" be able to create another user ?
- Should we introduce a "admin" role that can manage users (create, reset
password, delete) ?
- A mix of permissions ? (a developer can create other users but not remove
them nor reset (except its own) password )
>From there the second question regarding password management :
In the current situation, our default user (called "admin" , yeah a bit
confusing :) ) has a temporary password that must be changed the first time
he logs in.
- Do we want to keep this ?
- Shall we move to a script that creates a user(s) ?
- When we add a user through the admin UI, should we provide a password or
should it be generated and changed on first login ?
In other words, I think we must concretely spec out the user management for
the UPS and we could use this thread to discuss that !
We're planning to create a tool to be used inside our AeroGear Cordova
plugin projects, in order to automate the Jasmine test suite execution
inside emulator & devices. Initially we're targeting on Android & iOS
platforms and the tool will be available to the public through NPM
registry as a Grunt plugin.
Here is how we're thinking to implement it:
Step 1. Configuration in Grunt file will include:
- project configuration per platform:
- target directory: directory where the Cordova project will be
- name: project's name
- package: project's package
- version: the Cordova version to be used for creating the
- path: the path of an existing Cordova plugin in the filesystem
- git: will be used in the case where the plugin does not exist
in the filesystem and there is a GitHub repository for it
- url: the GitHub URL of a Cordova plugin
- target: the folder in which the GitHub project will be
- testsuite: the Jasmine test suite to execute inside the
- platforms: Android and/or iOS
- device ids: the device ids to be used in order to install the
cordova application (e.g APK in Android). If this is empty then the
Cordova apps will be installed to all the devices/emulators which are
present during the test execution
- cordova_libs: the cordova libraries (cordova-android, cordova-ios)
which are required to create a clean Android, iOS Cordova project
- path: the filesystem path which contains the Cordova library
- url: the GitHub URL of the Cordova library in case it does not
exist in the filesystem
- target: the folder in which the Cordova librray will be cloned
Sample Grunt file: https://gist.github.com/tolis-e/aba6b002c276bcf60a4a
Step 2. Setup the environment. If the cordova libraries are not present
in filesystem, they will be cloned from GitHub.
Step 3. We're planning to use our
https://npmjs.org/package/grunt-android-emulator to automatically start
Android emulators. iOS emulators automatic startup is under
Step 4. if a specific Cordova version e.g 3.0.0 is defined in Grunt file
then we will perform a git checkout of the specific tag inside the
cordova-android and cordova-ios. This way, the projects which will be
created on the next step, are compatible with a specific Cordova
Step 5. Clean Android, iOS projects will be created by using the
cordova-android, cordova-ios libraries which exist due to step 2
Step 6. Modify the Jasmine suites by adding a custom reporter which will
log the results on stdout (Android logcat in Android case).
Investigation is needed on whether something similar to Android logcat
exists for iOS emulators/devices.
Step 7. The plugin will be installed on the clean Android/iOS projects
by using https://npmjs.org/package/plugman I haven't tried plugman to
see how it works but in the worst case we will install the plugins by
modifying and copying files (config.xml).
Step 8. Build APK using ant for Android, execute the build script for
Step 9. Deploy APKs on devices using adb on Android. For iOS, fruitstrap
https://github.com/ghughes/fruitstrap might do the job. However, the
fruitstrap project is no longer maintained and it would make sense to
use a different tool. any idea?
Step 10. Attach a listener to logcat output and wait for test results.
Parse the results, aggregate them and exit the Grunt process either with
a success or failure status. It is under investigation how to transfer
the results from the iOS emulators/devices (see step 6)
This above idea is inspired from the Medic tool
https://github.com/filmaj/medic (Continuous integration setup for Apache
Cordova). Apache has recently created a new GitHub repo:
https://github.com/apache/cordova-medic and they are using a Couch DB in
which the Jasmine results are posted. Moreover afaik, the tool assumes
that the emulators are already started during the test execution and
their lifecycle is not managed by the tool.
sorry for the long e-mail :)
Let us know your thoughts
I want to open a JIRA issue related to our Cordova repositories but
there is not a such project in JIRA. Should we create a separate JIRA
project for that purpose?
AeroGear Cordova or AeroGear Hybrid would make sense
Good morning team, before I start to moving Jiras to the next release I
would like to hear some thoughts about
Keep in mind that we are targeting mid Nov and this is just my realistic
point of view.
There will need to be a bit of deprecation since the 2 new adapters are asynchronous and return a promise/callbacks and the other adapters are synchronous and return the actual data.
We are thinking of adding an option, "aysnc", the name is up for debate, which would only be valid for the memory and session/local adapters and would default to false and things would return as normal( this would also be removed in the next release and everything would be "async" ), but if true, then these adapters would return like the 2 new adapters, using callbacks/promises.
Now on to the Fallback Strategy:
Here is a use case:
I'm a user, i create an IndexedDB store, but the device/browser i'm using doesn't support it. I think there are 2 options we can go down here
1. The user gets an error back about IndexedDB being not support, just like regular. And they need to "opt-in" to the fallback stuff. this would be an option on the "add" of the Store. Maybe the actual Constructor?
They would also be able to provide a list of adapters to try which would override our predefined list.
2. Fallback is assumed and there is no option, it just happens, using our predefined list.
There is still the question of if the fallback is used, and a "Asynchronous" store falls back to a "Synchronous" one, what should be returned. I'm thinking what ever the return value of the "Async" one was.
I don't see this as breaking API since the "sync" store was not meant to be created "directly"
So if they create an IndexedDB store and it fallbacks to a memory adapter, this store will use the "async" model
Thoughts, comments, cat pictures,
To have something in the mean time we could use something like the eclipse formatter, because it can format JS has a ton of options and there are already a lot of external tools that use it:
So how about having something like this that will format our JS for us? We could integrate something like this in our build, or that or create our own CLI tool as long as we have something that will work so that we don't have to discuss formatting anymore, what do you think?
during the development of security bits in iOS I had come up with some questions which I will appreciate your input. In particular:
a) As described here  a passphrase is asked to be entered by the user and then we use PBKDF to generate the encryption keys which we will then encrypt user's data. The problem I see with this approach, is that if the user decides to change his passphrase we need to re-encrypt users’ data with the new key. A possible solution is to generate a random _symmetric key_ and then use PBKDF (with user’s passphrase) to encrypt that _symmetric key_. In that we stay independent of the user’s passphrase change. It can also help in scenarios where a separate PBKDF key can be used to encrypt the _symmetric key_ , generated by security questions (in case the user forgets his passphrase).
b) From my understanding, data can be decrypted on server since a shared secret is used (produced by Diffie-Hellman)? How can this be avoided? During my search came up with a 'Split Server-Side Keys’ concept described here . Basically two keys are generated one half resides on the client (generated by PBKDF) one on the server (random). The server can’t decrypt without possession of the client key and vice versa. Looked interesting
I've just had an idea for the Demo app needed for encryption .
Instead of doing a plain password manager, what about doing ChristmasSecret app. As Christmas season will be around our Security release, we could demo an app that encrypt very sensitive information as Presents brought by Santa Claus to friends and family.
present description, an optional photo, and toWhom field
Flow1 for symmetric encryption 
1. user opens ChristmasSecret app and is prompted for password to encrypt/decrypt
2. App decrypts Present photo/description/toWhom with password
3. App displays dashboard with post-it photo (UICollectionView display for a change of UITableView)
If present was encrypted with different password.Information can not be decrypted, display this present with generic present picture.
App will use AeroGear local storage solution.
Later we can think of other secanrios: we can also add query box to select all rpesent for John...
Flow2  will eveolved into an ChristmasSecret where you can share your present list with other persons (when buying present together etc…)
The idea is to keep the UI and the flows as simple as possible to focus on encryption code. We can add this 'demo' as part of a recipe of our Cookbook repo rather than a separate demo repo.