Keycloak integration and UPS Sender
by Bruno Oliveira
Good morning peeps,
I have a problem to solve which might affect the Sender and
all the related clients.
Previously, the UPS Sender was protected by the basic authentication
method[1], so anyone in possession of _PushApplicationID_ and
_MasterSecret_ is able to send push messages.
After the integration with Keycloak now everything under _/rest_
is properly protect by KC which is totally correct. Our sender is under
the same umbrella which means that now Bearer token authentication is
required[2] and Basic authentication won't exist anymore.
The consequence of this is the basic form being presented when you try
to send push notifications[3]. The problem didn't occur before, because
we were just using Basic authentication[4] instead of Bearer tokens.
Possible solutions:
1- After the removal of Basic authentication, move _PushApplicationID_
and _MasterSecret to http headers like:
-H "PushApplicationID: XXXXXX" -H "MasterSecret: 42"
IMO it sounds correct and reasonable for me.
2. Create a role specific for the sender like _push-applications_ and
dinamically add _PushApplicationID_ and _MasterSecret on Keycloak where:
username: _PushApplicationID_
password: _MasterSecret_
The implications of this alternative is the fact of have to manage those
credentials on the server side inclusion/exclusion/login
3. Implement another authentication provider specifically for the sender
and Basic authentication[5]
4. Do nothing. The consequences of this alternative is to implement
everything already done by Keycloak.js and manage session tokens by hand
on the admin-ui.
To me the first alternative seems to be more simple, but I really want
your feedback on it, once it affects the whole project.
[1] -
https://github.com/aerogear/aerogear-unifiedpush-server/blob/6c1a0d3fedea...
[2] -
https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js
[3] -
http://photon.abstractj.org/AeroGear_UnifiedPush_Server_2014-06-17_10-00-...
[4] -
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve...
[5] - https://github.com/keycloak/keycloak/tree/master/examples/providers/authe...
--
abstractj
9 years, 10 months
Aerogear Cordova Push Plugin: Actual vs Expected Results
by keithdmoore94
I am seeing behavior that is inconsistent with other native applications that
I have used as well as inconsistent behavior between Android and iOS. For
the sake of simplicity, I am going to leave the “foreground” flag out of
this discussion.
Precondition
Three push notifications have been sent by an external client. Let’s call
them “Push1”, “Push2” and “Push3”. They were sent in that order by the
external client. Let’s assume the client received them in that order as
well. Mobile application is not in the foreground.
Actions
User navigates to the notifications panel.
Android Experience
Android will only show the very last notification in the notification panel.
User touches the notification(“Push3”), the app is brought into the
foreground. The notifications are received by the app in the order in which
they were received. All the push notifications in the notification panel
are gone. First of all, I would have expected all three notifications to be
displayed in the notifications panel. Also, I would expect that the
remaining “Push1” and “Push3” notifications to remain in the notifications
panel and NOT be sent to the app.
iOS Experience
iOS will show all the apps notifications in the notification panel. User
touches the “Push2” notification, the app is brought into the foreground.
The “Push2” notification is received by the app. The others are NOT
received. All the push notifications in the notification panel are gone.
Here I would expect the “Push1” and “Push3” notifications to remain in the
notifications panel.
The behavior I am seeing seems inconsistent with almost all the other apps I
have used that support push notifications. Seems like the plugin should be
changed to have standard behavior and should be consistent across both
Android and iOS as much as possible. I am considering working on doing
that. Any thoughts regarding this ?
Thanks,
Keith D. Moore
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Cordova-Push-Plugin-Ac...
Sent from the aerogear-dev mailing list archive at Nabble.com.
9 years, 10 months
UPS console: server error response handling on client-side
by Lukáš Fryč
Hey guys,
I was looking into AGPUSH-720 and I got an perception that not all error
response do we actually know on the client-side.
We should establish a common pattern - contract between server and client -
which says how is a failure message transported from server to client, e.g.:
- response header
- response message body /w given structure
Right now, I've opened a PR for a generic failure handling mechanism that
can catch and report any error:
https://github.com/aerogear/aerogear-unifiedpush-server/pull/226/files
I plan to extend this error handling code dynamically as needed based on
response codes (e.g. 404=Request resource is missing) and contract
mentioned above ^.
Wdyt?
~ Lukas
9 years, 10 months
Current status of UPS 0.11.0
by Bruno Oliveira
Good morning peeps,
First I would like to thank Bill Burke, Stian, Sebastien and Lukas for dedicating
their time helping with Keycloak integration.
I think we are almost done, this is the current branch:
https://github.com/abstractj/aerogear-unifiedpush-server/tree/keycloak.js. And now most
of issues were gone and is also possible to display the current logged
in user.
Now I'm working on fix the sender endpoint, to be more precise we need
to remove the HTTP basic authentication for sending push messages
now that most of the endpoints are protect by Keycloak. If you try to
send a push message based on my branch you will see the basic
authentication form atm.
If you have a better idea, I'm all ears.
--
abstractj
9 years, 10 months
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
9 years, 10 months
UPS staging heads up
by Bruno Oliveira
Good morning,
At the present moment we have some critical issues to be fixed before
stage UPS server 0.11.0 and I'm holding it until Keycloak beta3 be released
with the solution for this issue https://issues.jboss.org/browse/KEYCLOAK-523.
More updates will come during the week, as soon as I get more
information.
Thanks in advance
--
abstractj
9 years, 10 months
More on AeroGear - iOS
by Yagyesh
1.
Recently, while working on GoogleDrive iOS sample i found that the app was
not being notified back if user chose 'Cancel' instead of 'Accept' on the
Google's OAuth permission page. The returned url from Google looks something
like this:
org.aerogear.googledrive:/oauth2Callback?error=access_denied
And below is the code snippet from requestAuthorizationCodeSuccess method of
AGRestOAuth2Module:
------------------------------
// extract the code from the URL
NSString* code = [[self parametersFromQueryString:[url query]]
valueForKey:@"code"];
// if exists perform the exchange
if (code)
[self exchangeAuthorizationCodeForAccessToken:code
success:success failure:failure];
----------------------------
If user denied permissions, 'code' would be nil and there is no else part. I
believe there should be a way to notify the app.
2.
Another thing that i could not achieve was multipart upload. I'm not sure if
i did anything wrong but no matter what i tired i always used to get 'Bad
request' error. If multipart upload works for iOS, is there any example that
i can refer to? If multipart is not tested throughly, it would be time for
me to bring up wireshark, see how the request is actually being sent over
http & hopefully fix multipart upload for iOS.
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/More-on-AeroGear-iOS-tp8157.html
Sent from the aerogear-dev mailing list archive at Nabble.com.
9 years, 10 months
