RE: [widgets] What does it mean to have an unavailable API

Hi Marcos,

requestFeature() from BONDI 1.0 is an asynchronous API that follows API design pattern:
http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#asynchronicity

requestFeature() is described in detail in:
http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf

section 4.3.2

"A call to the successCallback Function signifies that the request has been satisfied and that the corresponding JavaScript API is immediately available."

It means basically that you can directly use the requested API if the request to have it was successful.
You do not have to perform any further checks and there is actually a bunch of interfaces that are available, not just a single object.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Tuesday, June 02, 2009 7:50 PM
To: Jonas Sicking
Cc: Marcin Hanclik; Scott Wilson; Henri Sivonen; public-webapps
Subject: Re: [widgets] What does it mean to have an unavailable API

On Tue, Jun 2, 2009 at 7:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik
> <Marcin.Hanclik@access-company.com> wrote:
>> Hi Scott,
>>
>> In BONDI we have discussed the (has/request)Feature() for some time.
>> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf, section 4.3
>>
>> A few points for further discussion:
>> 1. feature (at least in BONDI) is an abstract thing, not just one function. So hasFeature() is simply optimized checking procedure. If you check for a feature and discover that it is available, you may/should/must assume that a set of functions is available. Otherwise, you have to check each function individually and basically you cannot assume that if one functions is available, then the other is as well.
>>
>> 2. requestFeature() adds dynamism to the Website content. Widgets express their dependency statically by <feature>.
>> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf B.2 specifies more details.
>
> Doesn't the requestFeature() make at least the security benefits of
> <feature> moot? In Another thread Marcos stated that one of the
> benefits of <feature> was that if a widget gets exploited, the
> exploited code couldn't get access to any features that the widget
> hadn't enabled using <feature>. However this does not seem to be true
> if the exploited code could simply call requestFeature() first, and
> then use the feature.
>

I don't know what the BONDI doc says, but this is certainly not what
should happen (unless something changed since I stopped working with
Bondi on this). The idea with getFeature, IIRC, is that you first
declare a feature, e.g., <feature name="foo:bar">, and then you can
ask for an pointer to it at runtime:

<script>
    var foobarator =  Bondi.getFeature("foo:bar");
    foobarator.crush().kill().destroy();

    var barfoo  = Bondi.getFeature("bar:foo");
    barfoo === underfined; // true
</script>


--
Marcos Caceres
http://datadriven.com.au


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Wednesday, 3 June 2009 10:24:55 UTC