We won't be breaking plugins. I don't want to move to this for the reasons
stated before. This code also is way less maintainable, and looks like it
could break easily. I really think that clarity should win out here over
an abuse of java reflection.
On 10 Jul,2014, at 17:15 , Anis KADRI wrote:
On 10 Jul,2014, at 17:15 , Anis KADRI wrote:
> I want to say that this should be default...but we won't change the API
> again and won't break plugins again.
Both could be supported at the same time, just by using a different base class
I want to say that this should be default...but we won't change the API
again and won't break plugins again.
On Thu, Jul 10, 2014 at 7:48 AM, Erik Jan de Wit wrote:
> Hi all,
>
> Created an plugin that does this:
> https://github.com/edewit/aerogear-reflect-cordova the repository also
> include
Hi all,
Created an plugin that does this:
https://github.com/edewit/aerogear-reflect-cordova the repository also includes
a example plugin that uses this. Also have a blog describing this a bit more
http://blog.nerdin.ch/2014/07/improved-cordova-android-plugin-api.html
Cheers,
Erik Jan
It does get complicated in a hurry. Using the technique in the Google
Maps plugin:
- getDeclaredMethod is documented to NOT return inherited methods which
limits exposure
- the signature passed to getDeclaredMethod also limits exposure
- annotations, as Andrew suggested, could further limit ex
On Thu, May 29, 2014 at 9:26 PM, Terence M. Bandoian wrote:
> Please correct me if I'm wrong but, as I understand it, the vulnerability
> stems from injecting a Java object into the WebView which, in API levels 16
> and below, exposed all of the public methods of the object (small 'o')
> including
Please correct me if I'm wrong but, as I understand it, the
vulnerability stems from injecting a Java object into the WebView which,
in API levels 16 and below, exposed all of the public methods of the
object (small 'o') including the methods inherited from the Object class.
-Terence Bandoian
Even even nicer might be to use annotations:
@ExecCall
private void someCall(JSONArray args, CallbackContext callbackContext)
On Thu, May 29, 2014 at 4:01 PM, Joe Bowser wrote:
> This plugin illustrates why applying this to the general case is a
> terrible idea. Here it's catching every type
This plugin illustrates why applying this to the general case is a
terrible idea. Here it's catching every type of exception, which is
correct since we don't know whether we're running on a device that
passes CTS. However, for example, if there's a permissions problem,
or a problem with the GPS b
I am with Joe, this is too big and breaking of a change for a small
semantic win.
Another approach might be to define an execute method in a plugin ( pick
one ) and have it self reflect, and call it's own exposed methods.
@Override
public boolean execute(String action, JSONArray args, Callbac
Erik,
I think it should be possible leave the platform plugin interface as-is,
and publish a plugin that does nothing but implement
reflection-based-execute. Then, plugin authors can opt to use that as a
base class for plugin development.
I hesitate to give opinions on this topic, except to say
On Thu, May 29, 2014 at 11:46 AM, Erik Jan de Wit wrote:
>
>> What is the benefit of using this logic? I personally don't see any
>> benefit, since this makes our code more complex.
>
> It would benefit the users as they don’t have to implement this boilerplate
> code of dispatching based on the
> What is the benefit of using this logic? I personally don't see any
> benefit, since this makes our code more complex.
It would benefit the users as they don’t have to implement this boilerplate
code of dispatching based on the string. And this logic will be then on the
android side where it
I could build a little prototype that shows what I’m talking about, how does
that sound?
On Thu, May 29, 2014 at 1:25 AM, Erik Jan de Wit wrote:
>
> On 28 May,2014, at 22:07 , Shazron wrote:
>
>> https://github.com/apache/cordova-ios/blob/50ca482c8e861c1aa480dadba726b1abbacbc0e1/CordovaLib/Classes/CDVCommandQueue.m#L193-L198
>
> Right thanks, that is how I expected it to work, so why
On 28 May,2014, at 22:07 , Shazron wrote:
> https://github.com/apache/cordova-ios/blob/50ca482c8e861c1aa480dadba726b1abbacbc0e1/CordovaLib/Classes/CDVCommandQueue.m#L193-L198
Right thanks, that is how I expected it to work, so why not use the same logic
in Android as on iOS? In Java one can al
https://github.com/apache/cordova-ios/blob/50ca482c8e861c1aa480dadba726b1abbacbc0e1/CordovaLib/Classes/CDVCommandQueue.m#L193-L198
On Wed, May 28, 2014 at 12:05 PM, Erik Jan de Wit wrote:
>
> >
> > I don't know, it very much could be. It could be that this makes sense
> in
> > Obj-C but not in
iOS has [object respondsToSelector:@selector(selector)] to check if
selector exists or not.
On 5/28/14 12:05 PM, "Erik Jan de Wit" wrote:
>
>>
>> I don't know, it very much could be. It could be that this makes sense
>>in
>> Obj-C but not in Java based on how they handle NoSuchMethod. I'd
>>
>
> I don't know, it very much could be. It could be that this makes sense in
> Obj-C but not in Java based on how they handle NoSuchMethod. I'd prefer to
> not have to rely on an exception being caught, especially since it could
> suppress other exceptions being thrown that I want to know abou
On May 28, 2014 11:21 AM, "Erik Jan de Wit" wrote:
>
>
> On 28 May,2014, at 19:06 , Joe Bowser wrote:
>
> > We don't want this pattern for Android because it is also more bug
prone.
>
> Doesn’t the same hold true for iOS?
>
I don't know, it very much could be. It could be that this makes sense
On 28 May,2014, at 19:06 , Joe Bowser wrote:
> We don't want this pattern for Android because it is also more bug prone.
Doesn’t the same hold true for iOS?
>
> On May 28, 2014 8:28 AM, "Erik Jan de Wit" wrote:
>>
>> So this security issue is only a problem if you are able to inject some
>
We don't want this pattern for Android because it is also more bug prone.
On May 28, 2014 8:28 AM, "Erik Jan de Wit" wrote:
>
> So this security issue is only a problem if you are able to inject some
arbitrary js code. If your app ships with it’s own html and js this is very
hard to do.
No, it's
So this security issue is only a problem if you are able to inject some
arbitrary js code. If your app ships with it’s own html and js this is very
hard to do. If the only reason for this is security then why not have the same
approach on iOS here methods are invoked dynamicly.
On 28 May,2014,
In case anyone is curious, here's why we minimize reflection:
https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/
On Wed, May 28, 2014 at 7:33 AM, Andrew Grieve wrote:
> Another reasonable approach would be to use a Map, but
> that can be implem
Another reasonable approach would be to use a Map, but
that can be implemented on top of what is currently exposed. I'm quite wary
of Reflection as well.
On Wed, May 28, 2014 at 10:06 AM, Joe Bowser wrote:
> The execute command exists for security reasons. We don't want any
> methods other tha
The execute command exists for security reasons. We don't want any
methods other than execute exposed to Javascript. I also prefer this
approach because it is less prone to less catastrophic bugs than using
Java reflection. We try and only use reflection when we have to.
On Wed, May 28, 2014 at
Hi,
When one is writing a plugin for android ATM the api that you have to implement
has a execute method that has the action as a string:
@Override
public boolean execute(String action, JSONArray args, CallbackContext
callbackContext) throws JSONException {
if ("beep".equals(action))
27 matches
Mail list logo
