I went once again through
http://lists.jboss.org/pipermail/aerogear-dev/2013-June/002901.html - which
says that Sender API should be fire&forget. It feels more like "maybe
fire"&forget, for instance it does not say that your credentials were wrong - or
it says, you need parse logs to get that information.
If I think about Android, iOS, JS solutions to communicate with
UnifiedPush we provide - Pipes - they always provide a callback to be executed
on success/failure. Could we add callback to Sender API? Or should not Aerogear
rather have something like Pipes abstraction for Java developers instead of
pretty dumb Sender API?
Where are u trying to log in. It doesn't say
Sent from my iPhone
> On Oct 17, 2013, at 7:15 PM, "Stefan Miklosovic (JIRA)" <aerogear-issues(a)lists.jboss.org> wrote:
> Stefan Miklosovic created AEROGEAR-1338
> It is impossible to log in for the second time or with different user simultaneously
> Issue Type: Bug
> Assignee: Unassigned
> Created: 17/Oct/13 7:14 PM
> When I register as admin and developer and I try to log in as admin in one tab and after that as developer in another tab (I changed password from default one for both users) I am unable to do so since error is thrown.
> I can not log in as admin twice (I log in as admin in one tab and I log in as admin in another tab while I am still logged in in the first tab)
> First of all, being able to be logged in for multilple users seems to be crucial. Secondly, when I try to log in for the second time while I am already logged in, I would expect appropriate error message to be displayed to me or I would be automatically redirected to application itself when credentials have not expired yet.
> Project: AeroGear
> Priority: Major
> Reporter: Stefan Miklosovic
> Security Level: Public (Everyone can see)
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> aerogear-issues mailing list
I just wanted to point something out that Matthias and I found this morning. Apparently, when you rename a folder in your repo, the history view for that file gets fragmented. If you go into the blame for that file, you can still see all of the last commits for each line and from there you can view the file history before the structure change. I just wanted to make sure everyone was aware so that contributors don't think we are removing their commits or doing anything else shady like that because on the surface it looks bad without a bit of digging. I feel like we are very careful with maintaining history and credit for work so just wanted to point this out.
With Christos we sit down to see remaining tasks/questions to achieve symmetric encryption.
See team agenda:
Here is the output:
- We created initial unit test for encryption/decryption
- Password derivation is done.
- Random generation helper done. Refactor of AGRandomGenerator. Split into different classes. Christos on it.
- Corinne created an initial encryptionimplementation using block encryption see
We would like to move to stream encryption using CCCryptorUpdate. Christos on the case. Work in Pogress.
- Encryption/Decryption could be a coslty operation we would like to do async work on different thread (dispatch_async->cipher->dispatch_main_queue )
Corinne to look at it.
=> impact on API, we would like to go forward with "encrypt:success:failure" async versions to avoid developer to use e.g.
- Question: where do we want to store random IV, encryption key (or just salt) used for encryption and neeeded to decrypt?
- What do we want for a demo?
Corinne to start a separate demo thread on ML: as the demo should be shared across JS/Android/iOS/cordova
One of the things that came up while discussing offline secure storage
on Android was how to query encrypted data.
The first ideas that I could think of were:
1) Load encrypted files/data/databases into memory, decrypt them, query
them, return results and GC the decrypted data.
2) magical phonetic encryption
3) Include queryable decrypted metadata along with encrypted payloads.
The payloads will not be queryable and only be decrypted if metadata
matches the query.
#1 has some benefits (easy to implement across platforms, doesn't
require a lot of work) and some draw backs (large datasets would eat
into available memory, whole dataset would be vulnerable to a VM attack).
#2 is a placeholder for better ideas.
#3 is interesting because it is a middle of the road approach. One of
the options for implementation I thought of would be to annotate fields
in the VO being stored as "privledged" and they would be the only ones
encrypted/decrypted when an object is stored or loaded.
What do you guys thing about having a aggregated feed and or a recent blog section on the site?