From MemberWiki

URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-02-16

Contents 1 Attendess 2 Minutes 2.1 Recent emails 2.1.1 DOM entity of a container 2.1.2 visibility:hidden 2.1.3 onPublish/onSubscribe 2.1.4 Unload detection for postMessage 2.2 Red-colored notes on wiki page 2.2.1 Should not throw exceptions 2.2.2 log function xss attacks 2.2.3 Howard's question about unsubscribe during subscribe processing 2.2.4 getScope() added (again?) 2.2.5 onSubscribe callback note 2.2.6 remove getSecurityAlertHandler 2.2.7 required vs optional params 2.2.8 HubClient.connect 2.2.9 Red notes at bottom 2.3 Containers chapter 2.4 Mashup Assembly Applications chapter 2.5 Best Practices chapter 2.6 Test suites

Attendess

• Jon Ferraiolo, IBM
• Javier Pedemonte, IBM
• Howard Weingram, TIBCO
• Eduardo Abe, IBM/ILOG

Minutes

Recent emails

DOM entity of a container

• http://openajax.org/pipermail/interop/2009q1/000919.html

A couple of questions related to the DOM entity that a Container represents:

1) IframeContainer creates and manages the actual IFRAME. InlineContainer currently does no such thing. For parity, I would like to have InlineContainer at least create a DIV. However, I can see the use case wherein a developer might want to create an inline client that does not actually exist in DOM, merely as a Javascript object. Thoughts on this?

2) IframeContainer holds a reference to the IFRAME DOM entity, but does not make that available the developer. If the dev wants to add a style to the iframe, currently they need to pass in an array of styles to the IframeContainer constructor. But this doesn't work well for a developer that wants to use CSS files. I suggest the following:

a) Provide a getter for the IFRAME object.

b) Add an ID to the IFRAME, along the lines of "IframeContainer_<ID>".

There is also the issue of the default styles that we add in the constructor (width/height=100%, border=none) -- they override anything specified in CSS. So we may want to do something else there...

Javier: IframeContainer has an iframe. Should InlineContainer create a DIV? But maybe client app has not DIV

Howard: I agree with the latter approach. Don't think we need to make a DIV. For inline, manager app may choose to create a DIV, but not required.

Javier: Call out that InlineContainer as a special case. Nothing is created by container. MA needs to create any necessary DIVs.

Howard: Needs more thought. Just don't create a DIV.

Jon: The question about styling properties. Just seems philosophically wrong that the Hub should affect any styling.

Howard: But need to avoid flicker.

Javier: Our style attribute would override any stylesheets

Howard: Pass in an ID or class name

Jon: Blunt object approach: pass in style, class and ID. If not provided, there are defaults for each.

Howard: My proposal - Iframe should be hidden initially, giving manager time to set properties. But probably need to set the ID.

Javier/Howard: ID could override, but provide a default

RESOLUTION: Take this offline

visibility:hidden

(discussion about leveraging visibility:hidden to deactivate client applications until connection handshaking is completed, versus timeout logic)

Jon: Need to verify that visibility:hidden doesn't let events through. It's on the page, but invisibible/deactivated, but need to verify that it doesn't accept UI events.

Howard: Hub should do the hiding

Javier: I agree

Howard: Should we restore width/height?

Javier: Up to manager app to do that

onPublish/onSubscribe

Javier: Always called no matter if MC or Container is doing the request

Howard: +1

RESOLUTION - Always called no matter if MH or Container is doing the request

Unload detection for postMessage

• http://openajax.org/pipermail/interop/2009q1/000918.html

This message is about an implementation detail and unless you are interested in IframeContainer implementations, you can ignore it.

If PostMessage is used to deliver an unload event to the Container, this will probably create a security risk. We need to use a tunnel iframe even for the postMessage case.

Rationale:

As far as I know, all implementations of PostMessage are event-based and asynchronous, so it may be possible for an event notifying the PMIframeContainer of an unload to be backlogged in a queue of other events. Meanwhile, the iframe would unload and be replaced by a phishing page. The unload notification may be delayed for an unspecified period of time.

A tunnel iframe with the same origin as the parent page is different. It accesses JavaScript on the parent page directly, and until the tunnel's onUnload handler function completes, the tunnel iframe is blocked from unloading, and this, in turn, blocks the sandbox iframe from unloading.

So we should use a tunnel iframe to detect unloads even in the PostMessage case.

Howard: We reached agreement in email

Javier: Just pointing out it isn't really a tunnel in the postMessage case. Just a way to pass the onunload event

Howard/Javier: Best to use the same parameter for FIM tunnel and postMessage unload

Jon: Let's keep tunnelURI unless we think of something better

RESOLUTION: tunnelURI applies to postMessage also

Red-colored notes on wiki page

(Stepping through the red-colored notes in the following wiki page)

• http://www.openajax.org/member/wiki/OpenAjax_Hub_1.1_Specification_Managed_Hub_APIs

Should not throw exceptions

Howard: Should say that callbacks should not throw exceptions, and that implementations should be secure in case exceptions are raised in callbacks.

Javier: You are right. We should put try/catch in our code.

(agreement that the try/catch logic should call the log callback function with exceptions)

Howard: Silently swallow and log

Javier: Must or should?

Howard: should

(discussion about say this once in spec or in section for each callback)

RESOLUTION: Callbacks should not throw exceptions. Implementations should be secure in case exceptions are raised in callbacks. Implementations should silently swallow and log exceptions that are raised.

RESOLUTION: Add text to each callback about should not throw exceptions.

log function xss attacks

Jon: This is the innerHTML assignment problem. If the log function does a dumb innerHTML assignment, then it might be possible for a malicious sw component to cause script to execute with priveleges

Javier: Leave this to the manager app

Howard: I agree. Need to put a comment into the spec

RESOLUTION: Add note to spec about log function and innerHTML dangers

Jon: What is the default logging function? None, right?

Howard: Yes. If not there, log calls get dropped.

RESOLUTION: Add note to spec about how if no log callback, log calls get dropped.

Howard's question about unsubscribe during subscribe processing

2009.02.17 Howard: if you call unsubscribe before asynchronous subscribe completes, you will never get an onComplete for the subscribe operation. Is this okay? It is easier to implement this way but may be more confusing for app developers. If we have to do a sub onComplete callback in cases where unsub is called before the sub's onComplete fires, there are state management implications.

Jon: Just warn people

Howard: OK with me. Just won't call on Complete in this case.

getScope() added (again?)

Howard: Complicated to explain, but it made the docs simpler

Javier: Would this ever be used?

Howard: Probably not. Let me think about this.

Javier: Will cause us to keep track of scope

Howard: Already doing that

Javier: OK

RESOLUTION: Howard will think about it. Go over it again next week.

onSubscribe callback note

2009.02.19 Howard: I added the following:

This function is only invoked when ManagedHub.subscribeForClient is called. It is not invoked when the Manager Application calls ManagedHub.subscribe.

Howard: I'll remove the new note and the new paragraph

Javier: +1. The text for onPublish is correct, and we will change onSubscribe to match.

remove getSecurityAlertHandler

RESOLUTION: Yes, remove getSecurityAlertHandler

required vs optional params

Jon: how do you tell which params are required or optional?

Javier: We are using brackets following JSDoc Toolkit

RESOLUTION: At top of wiki page, document the JSDoc Toolkit conventions that we are using

HubClient.connect

(discussion about mandating need to support reconnect)

RESOLUTION: Implementations must support reconnection

Red notes at bottom

Howard: I didn't get to the bottom. All of the red notes at the bottom have been resolved. I'll clean up the spec here.

Containers chapter

Jon: Appropriate content?

Javier: Good start

Howard: Maybe change title to "Developing Managed Hub Containers"?

Jon: Ok.

RESOLUTION: Change title to "Developing Managed Hub Containers"

RESOLUTION: Containers chapter is ready for final editorial review and then can move to subsequent final approval

Mashup Assembly Applications chapter

(we'll look at this in a subsequent phone call)

Best Practices chapter

(we'll look at this in a subsequent phone call)

Howard: Need to make changes relative to frame phishing alerts

Test suites

Jon: I was thinking about a similar approach to what Howard did for Hub 1.0 pubsub tests

Javier: But now we have to deal with async. Because of this, I went to DOH. I was thinking of continuing with that unless someone objects.

Howard: I'll look at the DOH stuff. Want to make sure the testing framework doesn't interfere with the execution of the tests themselves. Need a log approach for where client does a disconnect