FHIR Chat · docs: pull request 27: Remove `redirect`, add `postMessag... · cds hooks/committers

Stream: cds hooks/committers

Topic: docs: pull request 27: Remove `redirect`, add `postMessag...

Github Notifications (Mar 30 2017 at 19:11):

bkaney edited pull request 27

Github Notifications (Mar 30 2017 at 19:46):

isaacvetter commented on pull request 27

Hi Brian,

What would this mean for apps that aren't hosted in an iframe?

Isaac

Github Notifications (Mar 31 2017 at 00:48):

bkaney commented on pull request 27

Hi Brian,

What would this mean for apps that aren't hosted in an iframe?

Isaac

Hi Isaac -- postMessage enables cross-origin communication. This can mean iframe/parent, but also can mean when a window opens another window.

Github Notifications (Apr 09 2017 at 15:53):

jmandel commented on pull request 27

Thanks @bkaney! One aspect we should cover here (well, in any discussion of postMessage) is the target origin: we should specify how to lock this down on both sides, so that the CDS service's web UI (SMART app) can post messages _to_ a known target domain, and the EHR's listener window can filter by messages coming _from_ a known target domain. Thoughts on how to tie this back into our discovery/launch protocol?

Github Notifications (Apr 10 2017 at 19:29):

bkaney commented on pull request 27

Thanks @bkaney! One aspect we should cover here (well, in any discussion of postMessage) is the target origin: we should specify how to lock this down on both sides, so that the CDS service's web UI (SMART app) can post messages to a known target domain, and the EHR's listener window can filter by messages coming from a known target domain. Thoughts on how to tie this back into our discovery/launch protocol?

Hmm, good point. I wonder if there is a way to use the existing HookInstance identifier somehow? I'll think about this over the next day or so and update the PR.

Github Notifications (Apr 13 2017 at 20:57):

bdoolittle commented on pull request 27

Hi All,

postMessage seems like a nice alternative to the redirect url, we're really excited about its ability to enable a more responsive user experience. My team has a few points we'd like to add for consideration.

First, we agree with Josh that specifying targetOrigin when sending the message and checking the origin on the receiving side is a good security measure to add into the spec. Should the SMART App also be sending a security token (or other mechanism) to add an additional level of authentication?

Second, a web-based EHR may want to open the SMART App in a new tab rather than an iframe, this introduces the possibility that the user may exit the EHR before completing the SMART App interaction. In this case, there would be no window to send a postMessage to. Would the CDS Service know that the postMessage was not received? Should there be some acknowledgement from the EHR to the SMART App indicating that the EHR successfully received the postMessage? This way, the SMART App could indicate to the user that there was an error in notifying the EHR about the decision.

Third, there may be implementations where the redirect URL solution is more accessible than postMessage. Would it be reasonable for the hooks standard to be flexible and support both means of communication? The worry here is that the cds-hooks implementation becomes more complex.

Github Notifications (Apr 20 2017 at 19:52):

bkaney commented on pull request 27

I agree with @Josh Mandel. There is two more things I was thinking about.

1) I was thinking the hookInstance should be passed (as a query parameter, for instance) to the redirect URL. This would be helpful -or- necessary information for EHR to deal with navigation post-interaction.

2) I appreciate the "lowest common denominator" idea around a redirect URL. However, given a client-server EHR that is using some sort web dialog widget, having a javascript way to do this (e.g. postMessage) might be in fact the LCD...

Last updated: Apr 12 2022 at 19:14 UTC