Aerogear.js CORS & Android browser
by Apostolos Emmanouilidis
Hi,
I'm testing the CORS support on Aerogear.js.
Initially, I executed some CORS tests from Mozilla Firefox v21.0 and
received the Error: "jqXHR.getResponseHeader(..) is null aerogear.js
line 605" when testing the weblinking (attached screenshot).
However, I think that this error is not related to the AeroGear.js.
I managed to overcome this issue in Firefox by adding an extra header to
the service response which sets a server whitelist headers that browsers
are allowed to access:
Access-Control-Expose-Headers: Link
The problem is that it still fails on the Android emulator browser.
The header tests were also failing in Firefox and passed after adding
the following header in the Response headers:
Access-Control-Expose-Headers: next,previous
But on the Android emulator the header tests are failing. I captured the
requests using a proxy between the emulator and the REST service and
found that the constructed URLs for next and previous calls are wrong.
This happens because the custom response headers cannot be read.
In conclusion, I think that the Access-Control-Expose-Headers header is
not supported by the Android browser and for that reason the CORS tests
are failing. There is a relevant open issue [2] in the Android project.
[1]: http://api.jquery.com/jQuery.ajax/
[2]: http://code.google.com/p/android/issues/detail?id=56726
11 years, 6 months
Android keys (Re: AeroGear Push Message Format)
by Matthias Wessendorf
Summers, Passos,
wondering if we should/could honor "android" specific keys as well (similar
to the iOS keys that we "honor")
See:
https://github.com/aerogear/aerogear.org/blob/master/docs/specs/aerogear-...
-Matthias
On Thu, Jun 13, 2013 at 5:36 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> reminder, that ID is just the primary key :-)
>
> meaningful are "pushApplicationID" and "variantID"
>
>
> On Tue, Jun 4, 2013 at 3:17 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>> Luke
>>
>> once this landed, it will be "pushApplicationID" and "variantID" - the ID
>> is than meaningless (at least for PushEE server).
>>
>> -M
>>
>>
>> On Fri, May 31, 2013 at 6:45 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
>>
>>> plus plus
>>>
>>> On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org>
>>> wrote:
>>>
>>> https://issues.jboss.org/browse/AGPUSH-86
>>>
>>>
>>> On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com>wrote:
>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org>
>>>> wrote:
>>>>
>>>> somehow the device needs to say: "I belong to android variant"
>>>>
>>>> besides the @Id /PK, we can have a second field / column that
>>>> represents:
>>>> * PushAppID
>>>> * VariantID
>>>>
>>>> Yup. Having these would solve that
>>>>
>>>>
>>>>
>>>> Was that your question?
>>>>
>>>> On Friday, May 31, 2013, Lucas Holmquist wrote:
>>>>
>>>>> something that i was thinking about after doing some examples is that
>>>>> i'm not sure how i feel about using the PK's of each table as the
>>>>> identifier to register/broadcast clients.
>>>>>
>>>>> We are sort of giving meaning to data that really shouldn't have
>>>>> meaning. it should really only be used to identify the row. It might be
>>>>> better to have another key on each table/object that is the identifier.
>>>>>
>>>>> So in one of the examples i did, the app on the device will register
>>>>> the device with the push server, but i needed to also include the id of
>>>>> the variant instance
>>>>>
>>>>> i guess i'm thinking if someone migrates their database, these keys
>>>>> could get messed up.
>>>>>
>>>>>
>>>>> wdyt?
>>>>>
>>>>>
>>>>> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com
>>>>> > wrote:
>>>>>
>>>>> in selective push is:
>>>>> ==> variant: iOS + alias: mwessendorf
>>>>> a valid criteria too?
>>>>>
>>>>>
>>>>>
>>>>> yes. let me update the related doc(s)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>>>>
>>>>> TYPO:
>>>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>>>>> deviceType:iPadMini + alias: mwessendorf
>>>>> or
>>>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant)
>>>>> + deviceType:iPhone + alias: mwessendorf
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <
>>>>> matzew(a)apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <
>>>>> corinnekrych(a)gmail.com> wrote:
>>>>>
>>>>> When doing selective push query, is there any overlap between mobile
>>>>> variant (which I understand like mobile type which contains certificates)
>>>>> and device type?
>>>>>
>>>>>
>>>>> MobileVariant (or call it type) is something like "Android", or "iOS".
>>>>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
>>>>> Table", "Andrpid phone", android what not
>>>>>
>>>>>
>>>>> Sure.... ideally there are several variants:
>>>>> - iOS iPhone 5 optimised app in the app store
>>>>> - iOS iPhone 4s optimised app in the app store
>>>>> - iOS iPhone 3 optimised app in the app store
>>>>> - iOS iPad mini optimised app in the app store
>>>>> etc :)
>>>>>
>>>>> But, if there is only one variant, it's totally valid to install an
>>>>> iOS application (from the appstore), on an iPad and an iPhone;
>>>>>
>>>>>
>>>>> Both aimed at defining categories.
>>>>> Are those categories defined and fixed in the spec or can they be
>>>>> extended?
>>>>>
>>>>>
>>>>>
>>>>> I don't understand categories, here
>>>>>
>>>>>
>>>>> Can we do a selective push based on mobileType=mobile variant and
>>>>> alias=john@gmail?
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>>
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 6 months
iOS Basic/Digest Thoughts
by Christos Vasilakis
Hi,
iOS platform provides built-in implementations for authenticating against HTTP endpoints that support Basic / Digest authentication (among others). The workflow when iOS tries to authenticate against those endpoints is basically:
a) A credential storage singleton object provided by the system is consulted for authentication credentials. If credentials are found, the system proceeds with authentication. Understandably for this to work, the developer has to initially push the credentials to the system object (and remove when done).
b) If credentials are NOT found, the system tries to call the delegate method e.g. 'connection:didReceiveAuthenticationChallenge', giving a chance for the user to provide the credentials, by calling the appropriate methods on the authentication challenge object passed in.
AeroGear library, currently has a notion of pluggable authentication modules providing an interface for clients to implement 'login', and 'logout' methods, depending on the authentication scenarios that they try to support. This fits nicely with singleton credential storage approach, in the sense when doing 'login' and 'logout', we simply edit the credential storage adding or removing credentials appropriately. A branch for this work can be found here. For usage, have a look at our integration test
For testing purposes, another branch was created, this time letting the user to directly pass an NSURLCredential object initialised with the username/password combination during the Pipe configuration. Those credentials are internally stored and given back to the system by implementing the necessary callback . A usage example can be found in our integration test
advantages of using the singleton approach:
- fits nicely with the authentication mechanism we have in place (as an extension HTTPBasicDigestAuthenticationModule) so user familiarity when looking to add basic/digest support to the Pipe.
- we control the credential type e.g. 'NSURLCredentialPersistenceForSession'. This eliminates errors of using 'NSURLCredentialPersistencePermanent' and having the user to explicitly clear the keychain when trying to login with a different combination. For my search, many errors occurs because of this.
disadvantages of using the singleton approach:
- not sure if many iOS dev will like the fact of creating an Authenticator object instead of using directly an NSURLCredential object that are used to.
---
advantages of using the 'nsurlcredential' directly:
- users familiarity with the object.
- not explicit login logout request.
disadvantages of using the 'nsurlcredential' directly:
- error credential type can lead to errors.
With discussions with Matthias, we are more keen in following the HTTPBasicDigestAuthenticationModule approach instead of providing the NSURLCredential configuration option on the Pipe. Surely enough, in the documentation we will explicitly state that "login"/ "logout" methods, serve as a mean to setup internally the iOS authentication system so users don't have too (instead of calling remote endpoints)
Wdyt?
Thanks,
Christos
11 years, 6 months
aerogear-ios / Dropping support for iOS 4.x
by Christos Vasilakis
Hi,
we are considering starting from the 1.1.0 release of the aerogear-ios library to drop support for iOS versions 4.x. The main reason for this is to take advantage of the many improvements of our underlying networking library that we use (which dropped support for iOS 4.x version from its 1.0 already). Since most of the users of the platform are currently in iOS >= 5 (and soon 7 ;) we think that we can safely proceed to drop this version support.
What do you think?
Thanks
Christos
11 years, 6 months
packaging external Deps with Aerogear.js
by Lucas Holmquist
So AeroGear.js, the notifier stuff, has external dependencies on stomp.js / socks.js , depending on what adapter you use. ( probably also the vertxbus.js also )
The question is do we package these external dependencies with our JS libs or do we say "These are needed, so here are links to get them".
Using Bower, we can add the socks-client.js file, but not the others.
currently jQuery is a dependency, but we don't package that
THoughts?
11 years, 6 months
Versioning x Roadmap x Jiras puzzle
by Bruno Oliveira
Good morning all, today I was thinking about a problem that the other
projects might face with.
Our versioning policy is pretty straightforward
http://staging.aerogear.org/docs/reference/AeroGearVersioningPolicy/ and
to me makes sense. Here comes the problem, as you know
aerogear-security-shiro was released and would be crazy to start with
1.0.x, for this reason I started with 0.1.0. Question:
- Where 0.1.0 release should be into the roadmap?
http://staging.aerogear.org/docs/planning/roadmaps/AeroGearSecurity/
Might be confusing if we just add 0.1.0 into the roadmap.
- How to properly file jiras?
The correct would be 0.1.0 for jiras associated with
aerogear-security-shiro, but might be very confusing for newcomers when
they start to look at our roadmap.
- In the situation where you must bump the minor release, for example
aerogear-security 1.0.2. What's the appropriate approach to follow?
Create a new release on Jira and update the roadmap?
I'm asking these questions because is impossible our components have the
same version of the others with projects growth.
--
abstractj
11 years, 6 months
Aerogear-js v1.0.1 tests
by Apostolos Emmanouilidis
Hi,
We've added some tests for the Aerogear-js v1.0.1 [1] based on the tests
included in the Aerogear-js library. The Arquillian-QUnit extension (not
available on Maven Central repo) is used to deploy a rest web service,
execute the QUnit tests and propagate the results to JUnit.
--Tolis
[1]: https://github.com/tolis-e/aerogear-js-pipe-tests
11 years, 6 months
