CONVIO_API_IP_FILTER for browser-based applications

Options
Evan Parker 2
Evan Parker 2 ✭
Ancient Membership First Reply
in Blackbaud Luminate Online® & Blackbaud TeamRaiser® Discussions

quick question ... we are running into a potential issue with our Convio OPEN implementations.

apparently, an IP address must be declared on the back end (CONVIO_API_IP_FILTER) to allow an API call to the Convio servers. unfortunately, the three projects we have in the pipeline are all distributed, browser-based ajax programs which won't conform to the notion of an IP address and subnet mask, at least not one that is meaningfully enforced.

for the upcoming fiscal year, we won't have time/resources/infrastructure to develop server-hosted interactive applications. i am pretty sure that means we won't be able to have IP restrictions that are meaningful (ie. not wildcards for all for aspects) as our calls to the API will be coming in from all over the interweb.

has anybody else run into this issue? if this is actually a problem, is it going to be addressed in the near future? if not, i'm afraid we'll have to shelve our plans to use OPEN for this fiscal year.

Tagged:

Comments

  • David Hart
    David Hart ✭
    Ancient Membership Facilitator 1

    Creating mash-ups that use AJAX to access APIs hosted on another server is one of the real challenges on the Internet today, and fortunately there is a fair amount of innovation going on to help solve it. The first versions of the Open APIs used the technique of requiring a proxy server to get around the browser's same site security restrictions, but we recognize that this isn't a viable option for many folks. Other techniques that folks have been using historically are to use JSONP (JSON with padding) along with injection of script tags and using a Flash proxy to execute the cross-domain calls. I've been looking into a technique that is being embraced pretty widely now that uses hidden iframes for cross-domain communication. Here's a link to a pretty good article that explains it .

    Bottom line is that we expect to have a solution to recommend to customers this summer. As more information develops, I'll keep the community posted.

    Dave

  • Michael
    Michael ✭
    Ancient Membership Facilitator 2
    DavidHart :

    Creating mash-ups that use AJAX to access APIs hosted on another server is one of the real challenges on the Internet today, and fortunately there is a fair amount of innovation going on to help solve it. The first versions of the Open APIs used the technique of requiring a proxy server to get around the browser's same site security restrictions, but we recognize that this isn't a viable option for many folks. Other techniques that folks have been using historically are to use JSONP (JSON with padding) along with injection of script tags and using a Flash proxy to execute the cross-domain calls. I've been looking into a technique that is being embraced pretty widely now that uses hidden iframes for cross-domain communication. Here's a link to a pretty good article that explains it .

    Bottom line is that we expect to have a solution to recommend to customers this summer. As more information develops, I'll keep the community posted.

    Dave

    Dave, does that mean you guys are allowing the crossdomain.xml file now? Last time I asked about that, it was shot down roundly... the SWFProxy works great, but it requires the destination server have a properly configured xml file at the root specifying the domain the client is in is allowed to make remote requests. I was under the impression Convio wasn't going to do this.

    -mike

  • David Hart
    David Hart ✭
    Ancient Membership Facilitator 1
    Michael :

    Dave, does that mean you guys are allowing the crossdomain.xml file now? Last time I asked about that, it was shot down roundly... the SWFProxy works great, but it requires the destination server have a properly configured xml file at the root specifying the domain the client is in is allowed to make remote requests. I was under the impression Convio wasn't going to do this.

    -mike

    No, we're not currently considering allowing a crossdomain.xml file. We did look at Flash proxying as a potential solution, but it's a really bad fit with our configuration. I think that if you look at Yahoo, which has a wide-open policy file, you'll see that all the APIs hit a totally separate URL namespace from any of the interactive traffic. We're looking at implementing a javascript solution that leverages the iframe-based communication model described in the link that I referenced earlier. This should be easier for you to use, applicable to a broader set of constituents, and more secure. I hope to have some more details and some prototype code to post in the next few weeks. Unfortunately, I have several other commitments for our next release, so I had to put this on the back burner after getting a proof-of-concept done.

  • Michael
    Michael ✭
    Ancient Membership Facilitator 2
    DavidHart :

    No, we're not currently considering allowing a crossdomain.xml file. We did look at Flash proxying as a potential solution, but it's a really bad fit with our configuration. I think that if you look at Yahoo, which has a wide-open policy file, you'll see that all the APIs hit a totally separate URL namespace from any of the interactive traffic. We're looking at implementing a javascript solution that leverages the iframe-based communication model described in the link that I referenced earlier. This should be easier for you to use, applicable to a broader set of constituents, and more secure. I hope to have some more details and some prototype code to post in the next few weeks. Unfortunately, I have several other commitments for our next release, so I had to put this on the back burner after getting a proof-of-concept done.

    Dave, yes indeed. In fact, Yahoo has two completely seperated APIs. They have a very open policy for things that don't require authentication or access to member data. Things like maps, search etc. I think that there IS a fit for Convio in that area in places like TAF or advocacy posting APIs... anything really that a user could do on a Convio site without being formally logged in yet.

    By the way, the IFRAME element was omitted from the XHTML 1.1 spec. It wasn't actual deprecated (which is odd in and of itself), but an eye for forward compliance would dictate you not use iframes for anything. The alternative is to use the OBJECT element, but there are clearly some differences there.

  • David Hart
    David Hart ✭
    Ancient Membership Facilitator 1
    Michael :

    Dave, does that mean you guys are allowing the crossdomain.xml file now? Last time I asked about that, it was shot down roundly... the SWFProxy works great, but it requires the destination server have a properly configured xml file at the root specifying the domain the client is in is allowed to make remote requests. I was under the impression Convio wasn't going to do this.

    -mike

    I've actually got an update to my last response on crossdomain.xml files. We're beta testing a configuration now where you can configure crossdomain access for Flash applications through SDPs. It does not allow a site-wide crossdomain.xml file, but does allow you to provide access specifically to the APIs from Flash hosted on other systems. Here are some bullet points from an internal presentation that I did on how it works:

    Convio automatically creates a policy file for each of the APIs so that they can be accessed using Flash from other domains.

    To load the policy file for the CRConsAPI on organization xyz, you would use this URL:

    The list of sites that should be allowed access is controlled by a site data parameter

    The policy for each API needs to be loaded separately by the Flash movie

    Calls to the API need to include a trailing slash (e.g. CRConsAPI/?v=1.0… not CRConsAPI?v=1.0…

Categories