UPS 1.0.3?
by Vivek Pandey
Hello team,
Is UPS 1.0.3 release still in works ? I have a prod deployment of UPS 1.0.2
and was planning to upgrade to 1.0.3 (so that I don't have to migrate the
db).
Thanks,
Vivek
This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails.
8 years, 1 month
Fwd: I replaced XMLHttpRequest and image loading with a plugin, and wrote up my experiences
by Sébastien Blanc
Hi !
I just wanted to share that interesting post from the Cordova dev list. It shows how to delegate XMLHttpRequest and image loading to a native implementation.
Would we provide any advantage by using our iOS http lib and android Pipes over plain XMLHttpRequest ?
Also check the reply where another one have used the same approach to add certificate pinning , that could be an interesting source of inspiration since I know cert pinning is on the security roadmap [1]
Sébi
[1] https://issues.jboss.org/browse/AGSEC-196
Envoyé de mon iPhone
Début du message transféré :
> Expéditeur: Brien Colwell <brien(a)nextop.io>
> Date: 17 février 2015 11:42:48 UTC+1
> Destinataire: dev(a)cordova.apache.org
> Objet: I replaced XMLHttpRequest and image loading with a plugin, and wrote up my experiences
> Répondre à: dev(a)cordova.apache.org
>
> Hi All,
>
> I spent some time researching how much of the webview network stack I could replace with a Cordova plugin on Android. I wrote a post about it -
>
> https://github.com/nextopio/nextop-client/blob/master/docs/02.16.2015_CUS...
>
> The take away is that a Cordova can fully replacing the default XHR and image loading in the webview for async=true, but it can't do async=false (but who uses that anyway :/). This is cool because plugins can experiment with new wire protocols to get data to the client.
>
> Best,
> Brien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe(a)cordova.apache.org
> For additional commands, e-mail: dev-help(a)cordova.apache.org
>
8 years, 1 month
AGSEC components and versioning
by Bruno Oliveira
Good morning, I'm doing some housekeeping on AGSEC and would like to
know what works best for you.
For the further releases and for the sake of sanity at the roadmap, I'm
separating the security releases by component:
- Crypto
- Sync
- OTP
- push
- OAuth2
- offline
They are pretty much "virtual" because it project follows its own
release process and I just want to group by feature. For versioning what
would be better for you:
1. Versioning from scratch which pretty much means each component starts
with 0.0.1 and we increase accordingly with the progress.
2. Follow the Security roadmap versioning
(https://aerogear.org/docs/planning/roadmaps/AeroGearSecurity/). Which
means each component starting with 1.4.0 and increasing each one
independesing.
3. Follow each project versioning which means:
- sync: follows the same versioning for the sync server
- push: same versioning from the push server
Note: the idea would fail badly for OAuth2, Crypto and OTP
I'd vote for 2 to prevent confusion.
--
abstractj
PGP: 0x84DC9914
8 years, 1 month
Question on UPS dockerfile
by Matthias Wessendorf
Hello,
I am wondering if others noticed the same as well:
1) I started the vm (boot2docker start) and also did the exports, from
above printout
2) Next, running "docker run -it -p 8443:8443 aerogear/wildfly"
On the log I saw the WildFly booting up, but nothing for UPS/Keycloak on
the log visible.
3) Now, I cloned the repo, executed the build in
"dockerfiles/wildfly/unifiedpush-wildfly" (via "docker build -t
aerogear/wildfly .")
4) Next I tried again to get it running "docker run -it -p 8443:8443
aerogear/wildfly"
5) The WildFly console now shows the logs that you get when you deply UPS -
Now I could access "https://192.168.59.103:8443/ag-push" (after adding a
security exception)
Cool!
Now I did stop the VM (boot2docker stop)
On a new terminal, I started the vm (boot2docker start), performed the
suggested exports, and did run "docker run -it -p 8443:8443
aerogear/wildfly"
-> this time I got the UPS in the logs as well - wondering: is that related
to my previous build ? or was there just something wrong with my "first"
execute of "docker run -it -p 8443:8443 aerogear/wildfly" ?
Thanks!
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8 years, 1 month
Android Sync Status
by Summers Pittman
First the good news, I've refactored a lot of the xmpp-client code so
now the sync client is correctly handled by an Android service. This
gets around issues we were having earlier where the in-memory client
would get GCed while the doc was in the background as well as some
issues with loading documents when messages came in for the not
currently being edited doc.
Now the bad news, the past two weeks we've been focusing on using
Google's two way messaging for being the backbone of sync on Android for
alpha.1. One of the issues we knew about was the 4k message size limit
in GCM and that after a POC phase we were going to have to address it.
On Friday I noticed that the server was choking on messages much smaller
than 4K. Turns out that 4K includes all of the metadata around the
message in addition to the payload. I do not think the GCM bridge is a
good tranport for alpha.1 and (if everyone agrees) will be focusing on
the WebSocket based client.
One thing that this brings up that I didn't see in the AGSYNC Jira
(unless I'm blind) was how to manage the socket-connectivity interaction
on the clients. Basically a protocol / pattern for how we manage the
socket connections when the device gains and loses internet access or
switches networks. (For instance we should probably disconnect and
reconnect when the device leaves a cellular network and joins a Wifi
network)This is separate from collision handling/detection which does
have a Jira. If there isn't one (a connection handling Jira) should I
make one?
Happy Monday y'all,
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
8 years, 1 month
Storing the payload of the push notification
by Matthias Wessendorf
Hi,
earlier this week there was some discussion about storing the payload of
the push notifications ([1]).
Right now, we store some metrics (e.g. client that send the push, number of
devices, deliveryStatus etc) *and* the entire content of push notification.
This includes custom key/value pairs, the name of the sound file or even
the size of the badge.
Is all of that, storing the entire push notification payload really needed?
*No!*
What do we need, and why?
For counting the number of sent pushes (over time), the metrics are good
enough. We do *NOT* need any of the push content for that, that's correct!
But we want to do more on the 1.1.0 release. We want to introduce some
analytic features, to give our app developers (our users) a better
understanding of their push usage (see [2]).
In order to see details on how successful a push was (or not), we need to
only store the value of the alert key:
https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png
Ok, let's change that (see [3])!
For our app developers, using the UPS to reach out to their mobile app
users ("user engagement"), it's important to understand which push was more
successful:
- "Get 10% discount today" (sent on a Monday)
- "Our shop got new site, check it out and get 5% discount" (sent on a
Friday)
With the upcoming analytics we can help them to improve usage of their app.
User interaction is very important to a successful mobile application and
push is a key driver here! Our app developers want an app that is actively
used by their users (Nobody wants his app sitting on the last page of the
device or, even worse, in a folder together with Apple-Maps). Therefore
it's critical for our app developers to understand the relevance of their
push messages sent and how it impacts the usage of their app. That's why we
do the analytics described in [2]. And, yes - only the alert, not the
entire payload is needed for that.
<https://gist.github.com/matzew/b6459083f39394a892c5#privacy>Privacy
On the mentioned PR there was also some discussion about privacy violations
and stuff, when we store the content of the notification. An example where
*sensitive* data was sent over push was given. Something like: "Dear Mr.
Joe, your blood donation appointment was scheduled for 3 p.m"
1. This is not how push notifications are used for mobile apps. Push is
to signal, not carry actual (sensitive) data around.
2. In a lot of countries, at least almost all European countries, you
are not even allowed, by EU law, to give "data" to 3rd party providers
(like the push-networks of Microsoft, Apple or Google).
How does the actual (sensitive) data come to an app?
As said above a push is used to signal/ping an app, to indicate that there
is real data for the mobile app user. In the background the mobile app
tries to connect to the backend of the company, running/maintaining the
mobile app. After the real data was fetched, "local notifcations" are used
to give the user a visible notification, like "Dear Mr. Joe, your blood
donation appointment was scheduled for 3 p.m", or simply "New appointment
scheduled".
If the app was a chat system (and not a blood donation app from the Red
Cross), it would be the same: After a signal, the app connects to "chat
server" and receives the actual chat message from there. A reply would go
over the same "chat server" connection. None of this would go over a 3rd
party push network provider like Google, Microsoft or Apple.
What would we store from these silent notifications?
Nothing, since there is no alert, we would just store the metrics (e.g.
client that send the push, number of devices, deliveryStatus etc). If the
signaling is actually done with an alert (e.g. alert:"you got a new Chat
text" or "New appointment scheduled"), we would store that.
I hope this helps a bit to understand what is stored and also why we do
need a little bit of information.
BTW. our documentation already says that push is used for signaling, not
carrying actual data around, but based on this email I will update it to
have explicit information on best practices. Also, the documentation will
be clear about what (the alert only) is stored by the UPS, and why. (see
[4])
Greetings,
Matthias
- [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/478
- [2] https://issues.jboss.org/browse/AGPUSH-971
- [3] JIRA TO CREATE: to only store ALERT and not the full payload
- [4] JIRA TO CREATE: update doc regarding push message storage and best
practices
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8 years, 1 month
