Provide crossdomain.xml via menu callback and handle custom Kaltura server URLs

Working on this issue in my github repo, which is a fork of Kaltura's Drupal module SVN ("Andromeda" branch).

Initial commit: http://github.com/GiantRobot/drupal-kaltura/commit/1d5937ae8781f4611a6fe...

Issue: http://github.com/GiantRobot/drupal-kaltura/issues/issue/1

This patch applies (or *should*) to Kaltura's Andromeda in SVN.

This patch does NOT apply to kaltura-DRUPAL-6--1, I've checked that already. Backport should be trivial but not much point because the new release of Drupal Kaltura module is coming RSN.

First stab at generating Drupal-style patches via a Git repo ...

Will aim to include in 6.x-2.x-dev shortly if possible. Ref #848826: Release co-ordination issue: 6.x-1.5

Re-roll against kaltura-DRUPAL-6--2.

Patch above needs to also include a kaltura_update_6001() in kaltura.install to trigger clearing the menu cache.

I agree, some sites will need that setup, and for them the installation will require manual engagement (so possibly we should document the process better).

My logic with this patch was -

• If a site needs a more complex crossdomain.xml than the default Kaltura one, they'll need to customise the actual file to suit.
• If no crossdomain.xml file exists, then Drupal gets a chance to respond, and this module can insert its crossdomain.xml file (but other modules may also override).

So it's a convenience, but may be a good idea adding an option to disable, and documentation for people who want to manage it more manually you think?

I'm not convinced another module makes sense (but happy to hear reasons why that approach would make things better). I guess if there was such a module, I'd be all for using it, so this may be pure hubris :P

Are you suggesting an extra module, kaltura_crossdomainxml, packaged with this one? Or a more generic crossdomain module, to be installed separately?

My aim was to simplify the process by reducing a step of the installation (to help people like this and this - depending on another module seems like it doesn't do that.

I can see how this automatic provision might confuse someone who has requirements for a crossdomain.xml but needs to account for more than just Kaltura's crossdomain needs. Might also not work for people with Drupal installed in a subdirectory.

My suggestion is that we offer this feature as an optional inclusion (disabled by default), and include a comment in the crossdomain.xml to help site admins wondering where the hell this file came from. That (for me) covers the two classes of people who might find this addition troublesome.

Can you think of other cases where this doesn't make sense?

(I'm kind of liking the idea of a crossdomainxml module more now ... but keen to hear your thoughts more still.)

Yep, that's a compelling suggestion.

Looks like Services offers a crossdomain.xml callback as well, and SlideShowPro module would benefit from being able to add items to it. (Haven't dug too far into which other modules might want to offer crossdomain.xml yet. I'm not really a Flash guy.)

#623194: crossdomain.xml in services module. has a few things to think about. No show stoppers though (relies on clean URLs, well yes).

Looks like Services allows modules to provide other domains via hook_services_crossdomain_domain_policy() but there are probably more things to crossdomain.xml than just a whitelist of allowed domains, and that hook pretty much just adds <allow-access-from /> entries.

I do now think that if crossdomain.xml is to be provided from within Drupal space, it should be a standalone module which other modules can add to and depend on or make optional. I don't think it's the job of Services, or Kaltura, to provide that (but these modules should be able to suggest and leverage this new module).

Suggest we leave this task open until such a module is created. Keen to collab on it, but am committed to other projects to end of July.

Related: #887354: Don't require crossdomain.xml be installed in the Drupal site root

Updated for Drupal 7. This implementation makes the crossdomain.xml automatically appear after installation, and it automatically appends the Kaltura server URL to the list of allowed domains.

The bulk of #887354: Don't require crossdomain.xml be installed in the Drupal site root appears to be already committed. Need to test this against a custom Kaltura server to confirm it behaves.

This automates a previously manual step in the installation process, which IMO is a very good thing for getting new users onboard.

Update docs, restore a sample crossdomain.xml for sites unfortunate enough to be using ?q=path URLs or not installed to domain root.

And backport to D6.

Worked well for me at the time. Only reason it never got committed was lack of review from community.