we would like to evaluate "frontend-maven-plugin"  that could be used as
a mean to compile admin-ui distribution files into ag-push.war webapp
during Maven build time
This way we would enable people not familiar with node/npm/bower/grunt
tooling to compile latest and greatest,
and additionally avoid a need to compile and save into git repository.
Note1: web developer will still leverage Node tooling
Note2: this is post UPS 0.11.0 thing! ;-)
As pointed out in the JIRA, this may have its downsides,
so if anyone has some concerns please speak up now. :-)
It all started in that thread  talking about Android OAuth2 PR, but the discussion shifted on account management and storage. I think AccountManager deserves its own thread besides it’s a cross client topic (although implicit grant for pure web app is less a use case) so title is not right. Let’s fork the discussion.
Main goal of AccountManager is to store all the social access tokens per account. Here is the use case:
Some application may have to deal with several OAuth2 providers. For example in ios-cookbook, we have Shoot app which let you upload your photos to Google Drive(should change that to Google+ eventually), Facebook (and soon Instagram). When a user open Shoot for the first time and want to share to facebook, he will be prompted for OAuth2 grant, same thing for Google grant. The second photo will not trigger any grant as we’ve got the tokens. But if a user close the app and reopen it, we need something to store them if we don’t want to prompt again => AccountManager.
Encrypted or not encrypted?
Obviously access token and even more refresh token are sensitive data. Should we store them encrypted or in a secure storage like KeyChain or KeyStore? If we go that path a password is required to encrypt or access keychain, so we need an extra prompt for the user to enter password. For example, we can chage Shoot to require a password at first login to ancrypt/decrypt access token.
I would leave this decision to the end-use rdeveloper of the app. I would go for a configurable AccountManager, being able to take a store as demo here .
For now proposed API:
As explained here , use same method signature authz: like for AGAuthorizer. But when use on AccountManager it will create a authzModule and add an account to store tokens.
We need to be able to revoke tokens and remove account from account manager.
@summers : as you’re the guy behind Account Manager, if you can have a look to iOS PR   I would love to hear about your thoughts
I have started working on creating a CouchDB data-manager adapter which
uses the CouchDB REST API. The open-create database, read and save
operations are implemented  and tested both with encryption settings and
without encryption settings. If you'd like to give it a try, make sure that
you have enabled CORS on CouchDB side.
The remaining functions that needs to be implemented are remove and filter.
In addition, in order to keep consistent the data-manager API, we should
provide a way to remove all the documents in a CouchDB database-store.
a) Removing all documents in a CouchDB database
I'm thinking of fetching all the docs, using _all_docs endpoint which
returns _id and _rev (revision), mark them as _deleted and use the bulk
insert/update API to delete them. Not sure if this is a proper solution
since there might be a huge number of documents.
Another option would be to delete the database-store. This seems to be the
worst solution since the documents history will be permanently lost.
AFAIK, in order to perform filtering in a CouchDB database, a design
document and an appropriate view has to be created. My thought is that the
AGJS adapter should not create the view, instead we should assume that the
user has created the appopriate views and provide a setting in AGJS where
the view endpoint URl can be set.
Any ideas about filtering and the proper way to be implemented?
I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to.
Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can’t pretend to send a message like someone else.
What do you think?
Here's an initial version:
I tried to incorporate most wishes expressed in the other thread.
Most notable things:
- Landing page with an overview of stats, most active apps, and error
- Activity table shows both registration and notification events
- Activity table is per variant, and not all activity on the server.
Unless there's a usecase to have every event for every app/variant in a
table I don't think we actually need it. The important thing is to get
to error messages easily.
Things to do/think about:
- links/entry points to the activity table
- filtering the activity table
This is just the first iteration and we will improve on this.
Let me know what you think.
Good morning, after talking with Corinne and Christos we are planning a
IRC meeting on Monday (Jun 2) 12 p.m BRT, just after our team meeting.
The goal is to discuss the offline spec, what we've been planning and
how it could help OAuth2 implementation on the client side.
If you want to join, let us know.