UPS admin-ui distribution compiled by frontend-maven-plugin
by Lukáš Fryč
Hey guys,
we would like to evaluate "frontend-maven-plugin" [1] 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.
https://issues.jboss.org/browse/AGPUSH-672
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. :-)
Cheers,
~ Lukas
[1] https://github.com/eirslett/frontend-maven-plugin
10 years, 6 months
OAuth2 and Account Management
by Corinne Krych
Hello all
It all started in that thread [1] 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 [2].
For now proposed API:
As explained here [3], 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.
What’s next?
We need to be able to revoke tokens and remove account from account manager.
Thoughts?
@summers : as you’re the guy behind Account Manager, if you can have a look to iOS PR [2] [3] I would love to hear about your thoughts
++
Corinne
[1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-OAuth2-PR-...
[2] https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-190.ac...
[3] https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-190.ac...
10 years, 6 months
aerogear-js CouchDB data-manager adapter
by tolis emmanouilidis
Hi,
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 [1] 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.
Any ideas?
b) Filtering
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?
Thanks,
Tolis
[1]:
https://github.com/tolis-e/aerogear-js/commit/0cf952c36ea0f31aec2a6732d89...
10 years, 6 months
contacts-mobile-basic quick start
by Erik Jan de Wit
Hi,
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?
Cheers,
Erik Jan
10 years, 6 months
[QUICKSTART] Information for the mobile clients
by Sebastien Blanc
Hi all,
As we are almost done with the HelloWorlds, I think we can we start on the
Quickstart clients. As a reminder, the Quickstart will consist in a simple
Contact CRUD application with the possibility to send a Push Notification
to one of the listed contacts. Please refer to this
JIRA<https://issues.jboss.org/browse/AGPUSH-604> to
have more information.
The clients will have to communicate against secured REST endpoints. Joshua
and Pedro have started to work on that but nothing official is released
yet. I've tried out their
branch<https://github.com/pedroigor/jboss-wfk-quickstarts/tree/PLINK-392/contact...>
and
IMHO it's good enough to start using it for building our clients, the
restpoints won't change that much I believe.
And because I love you, I deployed on OpenShift a version of this secured
backend to ease the development of the clients !
If you browse to http://contacts-sblanc.rhcloud.com/ you will even see the
mobile web client. This deployed version contains also the Push Message
endpoint.
The branch of this deployed version can be found
here<https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_sec...>
.
But let's take a look at the diffrent REST endpoints :
<https://gist.github.com/sebastienblanc/10966803#crud-operations>CRUD
operations
I won't detail them here, since there is already a doc for that :
https://github.com/jboss-developer/jboss-wfk-quickstarts/blob/2.6.x-devel...
<https://gist.github.com/sebastienblanc/10966803#security>Security
*DISCLAIMER* : These might change
<https://gist.github.com/sebastienblanc/10966803#register>REGISTER<https://gist.github.com/sebastienblanc/10966803#register-a-new-user>register
a new user<https://gist.github.com/sebastienblanc/10966803#restsecurityregistration>
/rest/security/registration
- Request type: POST
- Request type: JSON
- Return type: JSON
- Request example:
curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H
"Content-type: application/json" -X POST -d
'{"firstName":"Jaime","lastName":"Lannister","userName":"jaime.lannister(a)westerlands.com","password":"hearmeroar"}'
http://contacts-sblanc.rhcloud.com/rest/security/registration
*NOTE* : We should use the convention to use the *email* as userName
<https://gist.github.com/sebastienblanc/10966803#getlogin>GET/LOGIN<https://gist.github.com/sebastienblanc/10966803#rerieve-a-user-and-log-hi...>Rerieve
a user and log him
in<https://gist.github.com/sebastienblanc/10966803#restsecurityuserinfo>
/rest/security/user/info
- Request type: GET
- Request type: JSON
- Auth : Basic Auth
- Return type: JSON
- Request example:
curl -v -b cookies.txt -c cookies.txt -u
"jaime.lannister@westerlands.com:hearmeroar" -H "Accept:
application/json" -H "Content-type: application/json" -X GET
http://contacts-sblanc.rhcloud.com/rest/security/user/info
<https://gist.github.com/sebastienblanc/10966803#logout>LOGOUT<https://gist.github.com/sebastienblanc/10966803#logout-a-user>Logout
a user<https://gist.github.com/sebastienblanc/10966803#restsecurityuserinfo-1>
/rest/security/user/info
- Request type: POST
- Request type: JSON
- Return type: JSON
- Request example:
curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H
"Content-type: application/json" -X POST
http://contacts-sblanc.rhcloud.com/rest/security/logout
<https://gist.github.com/sebastienblanc/10966803#push-rest-endpoint>Push
Rest Endpoint
I've added a new endpoint to push a message. In the deployed version, it's
hardcoded for now to send to the "quickstart" application created for the
https://quickstartsups-sblanc.rhcloud.com/ UPS instance, you will also have
to create the appropriate variants.
<https://gist.github.com/sebastienblanc/10966803#registration-with-the-ups...>Registration
with the UPS instance
I think the good flow would be to register with UPS once the login was
successfull. As *alias* the *email*should be passed
<https://gist.github.com/sebastienblanc/10966803#endpoint>Endpoint<https://gist.github.com/sebastienblanc/10966803#restcontactssendmessage>
/rest/contacts/sendMessage
- Request type: POST
- Request type: JSON
- Return type: JSON
- Request example:
curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H
"Content-type: application/json" -X POST -d
'{"author":"Jaime","receiver":"john.snow(a)thenorth.com","message":"Winter
is coming !"}' http://contacts-sblanc.rhcloud.com/rest/contacts/sendMessage
So here we can see that we pass data like :
{
"author":"jaime.lannister(a)westerlands.com",
"receiver":"john.snow(a)thenorth.com",
"message":"Winter is coming !"
}
To keep it simple, the client should always pass a hardcoded value for the
message , we don't want (for now)to add any complexity to the clients by
adding an extra dialog to enter custom messages.
author and receiver should contain the emails as we used that for the alias in
UPS.
So, I hope all this will help to boostrap the client's work. Remarks,
questions ?
(the content of this email is available
here<https://gist.github.com/sebastienblanc/10966803>
)
Sebi
10 years, 6 months
First go at stats/activity wireframes
by Hylke Bons
Hey,
Here's an initial version:
https://raw.githubusercontent.com/hbons/aerogear-design/master/Unified%20...
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
messages
- 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.
Thanks,
Hylke
10 years, 6 months
IRC meeting for Offline spec
by Bruno Oliveira
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.
--
abstractj
10 years, 7 months
