Open jmandel opened 11 years ago
Current status on dev_rest
:
oob
or also accept callback URLs via oauth_callback
param in the request? This is how it's currently implemented, the server disregards passed-in callbacks.frameable
is probably the default for most apps, should we assume apps are frameable unless they have an optional flag, possibly standalone
, set to TRUE?Current status on dev_rest
:
oob
is required meaning oauth_callback
parameters will be ignoredstandalone
which is true for every app that does not run in a frame containerI've put my ae-reporting app on AppFog, it can run standalone or in the UI frame. If you just launch it you can see how the login/patient selection is handled: http://ae-reporting.aws.af.cm/
(Note the rule checking doesn't work in the online version)
Very nice! A couple of thoughts:
Do both behaviors result from the same manifest file? Is this the intended
I lost context when I had to stop and register in the middle of the 1st app
On Wed, Feb 13, 2013 at 7:02 AM, Pascal Pfiffner notifications@github.comwrote:
I've put my ae-reporting app on AppFog, it can run standalone or in the UI frame. If you just launch it you can see how the login/patient selection is handled: http://ae-reporting.aws.af.cm/
(Note the rule checking doesn't work in the online version)
— Reply to this email directly or view it on GitHubhttps://github.com/chb/smart_project_management/issues/85#issuecomment-13497644.
Yes, it's one manifest and actually pretty simple:
The index page checks if record_id
is present and if it isn't, redirects to login/record selection, which returns back to the index page with record_id
set. This is always set when run from the iframe. Then the OAuth dance starts (unless a token for the record/base_api combination has been stored already).
Ah, yes, if you have to register then it loses context. I had to work around this for Indivo a while back, I probably won't get to replicate this any time soon. But as you say, very special case.
If you like the records-table then good news: it has been merged into dev
. :)
Great -- and there's a separate piece in the manifest for "break out of iframe into a new window when launched from the container", which isn't set for this app?
On Wed, Feb 13, 2013 at 10:21 AM, Pascal Pfiffner notifications@github.comwrote:
Yes, it's one manifest and actually pretty simple: The index page checks if record_id is present and if it isn't, redirects to login/record selection, which returns back to the index page with record_id set. This is always set when run from the iframe. Then the OAuth dance starts (unless a token for the record/base_api combination has been stored already).
Ah, yes, if you have to register then it loses context. I had to work around this for Indivo a while back, I probably won't get to replicate this any time soon. But as you say, very special case.
If you like the records-table then good news: it has been merged into dev. :)
— Reply to this email directly or view it on GitHubhttps://github.com/chb/smart_project_management/issues/85#issuecomment-13508889.
Yes, if you set the standalone
flag our container would open the app in a new tab/window. No, it's not set for this app.
Open issue:
"frameable"
boolean to app manifest"frameable":true
apps just as we do today but render the app'sindex
+record_id={}&api_base={}
"frameable":false
apps by rendering a clickable link withtarget=_blank
window.top || window.opener
as the source for thejschannel
get_credentials
step from SMART Connect launch flow + simplify the smart connect tokens approach!