[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter

[Tadeas Kriz]

I believe that’s how it was before the change, am I right? I think that the proposed solution, to switch back to generated tokens might be the most stable a way to go.

—
Tadeas Kriz

On 25 Jul 2014, at 02:49 pm, Karel Piwko <kpiwko at redhat.com> wrote:

> Long term, we want an implementation that works on all servers. If some 
> of them reject path params with '/', we need to token encode it somehow.
> 
> According to https://wiki.mozilla.org/WebAPI/SimplePush/Protocol , 
> EndpointURL should be exposed to application. Which does not mean that 
> it must be exposed to via UPS, right? As UPS is *THE* application to 
> which EndpointURL is exposed to.
> 
> UPS can translate {deviceToken} to EndpointURL. We just need a way how 
> to generate unique {deviceToken} on client. Would UUID work? 
> EndpointURL can become part of JSON [1].  
> 
> Such change would mean that clients can't use SP server directly but 
> have to go through UPS. This makes more sense then current setup to me.
> 
> Karel
> 
> [1] 
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74
> 
> On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf 
> <matzew at apache.org> wrote:
>> 
>> 
>> 
>> On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz <tkriz at redhat.com> 
>> wrote:
>>> 
>>> —
>>> Tadeas Kriz
>>> 
>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius 
>>> <daniel.bevenius at gmail.com> wrote:
>>> 
>>>>> 5. don’t use the url as a deviceToken (might not comply with 
>>>> Mozzila’s SimplePush specs)
>>>> The deviceToken is an UPS concept and there is nothing in the 
>>>> SimplePush spec which is violated in this case. 
>>>> 
>>> I thought that deviceTokens were changed from a generated value to 
>>> the URL just to comply with Mozzila’s SimplePush specs.
>> 
>> Nope
>> 
>>> Matzew, why was the generated token removed then?
>> 
>> It was the channelID before - but that should not be exposed.
>> In GCM devices are identified via registrationID
>> In APNs devices are identified va deviceToken
>> (both are somewhat the same - but different names)
>> 
>> In SimplePush devices are identifeid v/ the URL of the pushEndpoint 
>> (a backend uses that endpoint to notify _THAT_ client, regardless of 
>> how many channels it has subscribed)
>> 
>> So, that lead us to make the change (see history of this threa)
>> 
>> -M 
>> 
>> 
>> 
>>> 
>>>> I'm not sure about what the best option is for UPS thought. Would a 
>>>> regex in for the @Path annotation work perhaps, something like:
>>>> 
>>>> @DELETE
>>>> @Path("{token, .+}")
>>>> public Response unregisterInstallations(
>>>> 
>>> 
>>> What do you mean by that regex? The problem is simply the “%2F” 
>>> in the token (which is an URLencoded simplepush url) and it’s 
>>> being revoked long before it hits the RestEasy (which does the 
>>> routing according to what’s in the @Path).
>>> 
>>>> 
>>>> On 25 July 2014 10:32, Tadeas Kriz <tkriz at redhat.com> wrote:
>>>>> 
>>>>> —
>>>>> Tadeas Kriz
>>>>> 
>>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko at redhat.com> wrote:
>>>>> 
>>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <tkriz at redhat.com> 
>>>>> wrote:
>>>>>>> 
>>>>>>> It should not. For hibernate, it’s just a string like any 
>>>>> other.
>>>>>>> The problem might be in the configuration of JAX.RS/RestEasy. If
>>>>>>> I’ll have some time today evening, I’ll try to fix it, it 
>>>>> should
>>>>>>> be an easy fix.
>>>>>> 
>>>>>> Last famous words? ;-)
>>>>>> 
>>>>> 
>>>>> I shall never say “an easy fix” again.
>>>>> 
>>>>>> But I agree. Everything is string and URL encode should happen on
>>>>>> client while server should automatically decode and work always 
>>>>> with
>>>>>> just decoded string. If we need to encode twice, something is 
>>>>> wrong.
>>>>>> 
>>>>> 
>>>>> Anyway, the 400 Bad request response is made by the tomcat itself, 
>>>>> disallowing the use of %2F as a path parameter. This will probably 
>>>>> apply on other web containers.
>>>>> 
>>>>> Possible solutions with their disadvantages:
>>>>> 
>>>>> 1. well-documented double-encoding of the URL (might be confusing)
>>>>> 2. use @QueryParam instead of @PathParam (breaks the api 
>>>>> consistence, as every other call would still use @PathParam)
>>>>> 3. allow @QueryParam (again, breaks the api consistence, but only 
>>>>> for the SimplePush)
>>>>> 4. find another encoding (Base64 for URL = URLEncode then Base64 
>>>>> encode)
>>>>> 5. don’t use the url as a deviceToken (might not comply with 
>>>>> Mozzila’s SimplePush specs)
>>>>> 
>>>>> What do you think guys?
>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev