• Drupal 7 Module
  • Project Page: http://drupal.org/sandbox/JupiterIII/1627430
  • Git Repository: git clone --branch 7.x-1.x JupiterIII@git.drupal.org:sandbox/JupiterIII/1627430.git
  • Multisite Views provides the ability to bring content across sites via Views. This module uses the cURL php extension to send multiple GET requests to a menu callback, which performs a views function to gather the results, then sends them back across to the primary site. Multisite Views then appends the data to the original view, and performs the view's sort with the new content. (This module must be installed on both sites, and have cURL available to work).
  • Future Development: I plan to implement use of the HTTPRL module as an option instead of cURL. HTTPRL doesn't require a php extension, so it may be more favorable for some users.

Ventral.org analysis:
http://ventral.org/pareview/httpgitdrupalorgsandboxjupiteriii1627430git-...

Comments

skipyT’s picture

skipyT commented
Status: Needs review » Needs work

Hi,

Nice idea to make this. But I think you need some work to handle callback access for the views.

Suppose we have 3 fields which are accessible only by connected users, how can I get those values? Won't work, because the server call doesn't authenticate any user when you get the results.

Do you want to allow anybody to fetch your views results like this? You don't need some authentication? If I check the page source and the divs are containing the views names I will be able to make custom requests to your server every time :P

I think also you need to verify if the parameters sent in _GET are correct. You don't want to filter them at all? Also you should send back some error message if no valid response, at least a 404.

JupiterIII’s picture

JupiterIII commented

I think I understand what you're saying. My initial thoughts for a solution:

Textfield Option in my module menu which stores a keyword in variables table. Whenever a request is sent from my client function, the server requires a matching hashed key on the other side (meaning the keyword would need to be set on both sites). Would that suffice?

The other suggestions you made will be easy to implement (_GET validation and simple response for failed requests).

JupiterIII’s picture

JupiterIII commented
Status: Needs work » Needs review

Alright, I've switched from GET to POST, added a hashed key validation, and a 404 response if validation fails OR the view doesn't exist. Thanks for the response skipyT.

skipyT’s picture

skipyT commented

I would use a custom string for the hash. Not only a static text.

Because if I get your first request, all the requests will work with the captured hash text.

I propose you to use an OAuth 2.0 authentification and perhaps an IP filtering also.

Or at least you can do the following: the hash could be something like: hash(serialize($request_params).$secret_token.$time);
and you send the time() in the params.
This will allow to have different authentication token for different requests and it will be harder to guess.

JupiterIII’s picture

JupiterIII commented

Okay; couple of things:

1. I don't know much about OAuth. It looks very difficult to learn and use, and without any quality tutorial material (I can't find any), I'm afraid that's not really an option, unless you could provide a snippet for how it should be used.

2. The hash suggestion seemed valid, though I didn't really understand the use of both serialize($request_params) and $time, as they'd both be sent through the POST variable, they'd each be equally manipulable (so I omitted the request params and just went with $token.$time. This should make it nearly impossible to guess the token.

3. I really appreciate the responses, taking the time to read into the module and making sure it's secure. For some reason I had this idea that as long as I use drupal-established functions, it would always be secure. This is not the case! Especially with cross-site requests.

JupiterIII’s picture

JupiterIII commented
Status: Needs review » Needs work

I've found some bugs. My apologies.

JupiterIII’s picture

JupiterIII commented
Status: Needs work » Needs review

Bug (I left out user access checks on config pages) has been fixed, and I added formatting to the "Test" page. Please review!

anwar_max’s picture

anwar_max
Primary language English
commented
Issue tags: +PAreview: security

Manual Review:

multisite_views_settings_view() The output of this function is vulnerable to XSS exploits. If I enter

alert('XSS');

as multisite_views_default or multisite_views_default_clean I get a nasty javascript popup. This allows an attacker to pass malicious script code to the site administrator. You need to sanitize user provided input before printing it. See http://drupal.org/node/28984

anwar_max’s picture

anwar_max
Primary language English
commented
Status: Needs review » Needs work
JupiterIII’s picture

JupiterIII commented

Could you provide a screenshot or some more details? I'm having trouble reproducing that issue.

JupiterIII’s picture

JupiterIII commented

Please? Or at least provide a bit more description on the fields you're using to cause the JS popup.

skipyT’s picture

skipyT commented

The XSS attack (Cross-site scripting) which injects client-side script via a browser text field or textarea.

You can avoid this type of attacks if you filter out all the user provided data with: http://api.drupal.org/api/drupal/includes%21common.inc/function/filter_x...
or http://api.drupal.org/api/drupal/includes%21common.inc/function/filter_x...

JupiterIII’s picture

JupiterIII commented

The filter should be used on submit (before it enters the DB) or on page load?

JupiterIII’s picture

JupiterIII commented
Status: Needs work » Closed (won't fix)