| Project: | Services |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Hi,
Current implementation of crossdomain.xml policy is broken in services (6.x is also affected). This is a short list of issues with this feature:
issue #620938: Fatal error: Call to undefined function services_get_keys(), actually it is a mess of stuff from both modules: services only allows to use the webservices from current domain or subdmains, and keyauth grants access to domains in key settings.
Services module handles 'crossdomain.xml' file request through the menu system, so if "clean urls" is not enabled, nothing will be returned
The information of the crossdomain.xml file currently is innacurate, as it does not include security policy regarding https or port.
Services module is beaking other modules usage of crossdomain.xml file, as it simply hijack the request to the server.
So.. this is the current proposal list for crossdomain.xml file handling:
1 Forget about it, instruct module users about how to build crossdomain.xml files (including keyauth information) and remove the code.
Offer an exportable version (instead of hijack the file request) to the module user so he can put the crossdomain.xml file when and where he wants to, also merging with other files
Keep handling menu entry for crossdomain.xml request, (inform the user that if 'clean urls' are not available the file should be created manually).
Handling crossdomain.xml from the menu system, verify that no other crossdomain.xml file exists in the file system, if it exists, inject the xml entries regarding services usage.
Rewrite an API to handle crossdomain.xml files, and alter other module maintainers to stick to service crossdomain API if they should use a crossdomain.xml file
It worths a discussion.. remember, #drupal-services channel on freenode.
Additional "crossdomain.xml" information:
Introduction
Security meassures
#1
uuuh too many li items, and hitted submit instead of preview by error.. :/
#2
Hi ilo,
I just spotted the same thing as http://drupal.org/node/620938 while working on my endpoints (my very unofficial 3.x draft) for services and rewrote services_crossdomain_xml() as follows.
<?php
/**
* Callback for crossdomain.xml
*/
function services_crossdomain_xml() {
$output = '<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">'."\n";
$output .= '<cross-domain-policy>' . "\n";
$domains = module_invoke_all('services_crossdomain_domain_policy');
drupal_alter('services_crossdomain_domain_policy', $domains);
foreach ($domains as $domain => $info) {
$output .= ' <allow-access-from domain="' . check_plain($domain) . '" />' . "\n";
if ($info['subdomain_wildcard']) {
$output .= ' <allow-access-from domain="*.' . check_plain($domain) . '" />' . "\n";
}
}
$output .= '</cross-domain-policy>';
services_xml_output($output);
}
/**
* Implementation of hook_services_crossdomain_domain_policy().
*/
function services_services_crossdomain_domain_policy() {
// Allow our own domain and it's subdomains
return array(
$_SERVER['HTTP_HOST'] => array(
'subdomain_wildcard' => TRUE,
),
);
}
?>
Maybe this covers at least one or two of the points in your list. It doesn't cover all of them that's for sure :)
It would be nice to go all out on this one and use the DOM, allowing even more flexible alters. We would probably have to cache the results to keep it snappy.
The checking for and loading of any manually created crossdomain.xml file will not help us, as file system always trumps menu system unless special .htaccess stuff is written, but honestly who *doesn't* use clean urls. But extensibility & export help/instructions are needed.
#3
Thanks Huggo.. I'm scared, because we are just relying in the menu system, and that will not work at all when "clean urls" is not enabled. (try inurl:?q=node at google.. 29 Million unfiltered entries is not "Nobody"). I will not recommend to use this approach without the consensus of other module maintainers having their own crossdomain.xml. Services will hijack any chance of their modules to work.
So the feature will not be at all 'functional', if we depend on something external to Drupal: the http redirect, I would preffer not to handle it then.
#4
if other modules might use there own crossdomain when can build a crossdoamin drupal hook implementation and also a drupal_alter function to prevent collision.
what do you think about that option?
further more the services module can to see if the srever is using clean URLs and act accordingly
#5
@gavri that's what
<?phpdomains = module_invoke_all('services_crossdomain_domain_policy');
drupal_alter('services_crossdomain_domain_policy', $domains);
?>
...is for in the above example.
#6
sorry i didn't see it.