OpenF2 / F2

Redefining web integration for the financial services community
Apache License 2.0
129 stars 62 forks source link

Add support for cross-domain Apps #270

Closed timburcham closed 3 years ago

timburcham commented 8 years ago

When working with apps loaded cross-domain into a container, one of the common challenges encountered is that any relative paths in the app are executed in the scope of the container, and cannot be found. It would be great to see an addition to perhaps context, or the overall manifest of an app, allowing the app to declare its own FQDN, such that the app itself could later reference this parameter, and make appropriate requests for additional assets or JSON data.

The only known workaround for this at present is to hardcode FQDNs into the apps themselves, which is less than ideal from a build pipeline and deployment pov.

Reference example on a possible solution (see appBaseUrl param listed below):

{
 "name" : "My App",
 "appId" : "com_myfirm_myapp",
 "description" : "My Awesome App",
 "manifestUrl" : "http://myawesomeapp.com/apps/com_myfirm_myapps.js",
 "context" : { "myParam" : true },
 "appBaseUrl" : "http://myawesomeapp.com"
}
timburcham commented 8 years ago

Alternately, '//myawesomeapp.com' for a protocol-less request

brianbaker commented 8 years ago

similar to #73 ?

qrider commented 8 years ago

Looks like #73 is tagged with version2. I could be wrong, but I don't think this would necessarily be a breaking change.

timburcham commented 8 years ago

Happy to close this if it's a duplicate, but agree with @qrider on this not being a breaking change, necessarily. Sounds like @qrider is looking at cleaning up roadmap, perhaps that pulls #73 out of 2.0 and into a sooner version.

brianbaker commented 8 years ago

I think maybe the reasoning for #73 being pushed to 2.0 was because 2.0 was going to go the AMD route which already has some functionality similar to this.

timburcham commented 8 years ago

Specifically for this issue (slightly different from #73), here is some pseudo and real code from my own testing that will support this. I'm doing this in a local example where I'm simply modifying the manifest request before it's sent:

if (F2.isLocalRequest(a.manifestUrl)) {
    console.log('local');
} else {
    var baseUrl = '';
    var urlTokens = a.manifestUrl.split('//');
    if (urlTokens.length > 1) {
        console.log(urlTokens);
        var baseUrlTokens = urlTokens[1].split('/');

        if (baseUrlTokens.length > 0) {
            baseUrl = '//' + baseUrlTokens[0];
        }
    }

    a.manifestBaseUrl = baseUrl;

    console.log('c_', a);
}

In turn, you can then reference this Url in the app's requests which would otherwise be hardcoded or relative:

$.ajax({
    url: this.appConfig.manifestBaseUrl + '/data-apis/storage/getWatchlist',
    type: 'GET',
    context: this
}).done(function(response, status) {
//
brianbaker commented 3 years ago

close in favor of #73