CiviCRM Community Forums (archive)

Is there a chance to include a CiviEvent registration in an external webpage. The problem is that we have a Drupal/CiviCRM as our intranet/crm and a lot of different project websites for different purposes (mostly joomlas & wordpresses) but we want to track all events via Civi.

So the options I can think of is
a) include the registration via an iframe
b) make a registration on the external website via specific plugins and then import them via csv

both are ok but not perfect ...

thanks werner

I'm also interested in doing this, but instead of doing it with an external site, I need to display event information inside an Organic Groups page.

In Drupal, it's pretty simple to display content from one node in another using the following snippet:

<?php
echo node_view(node_load(4));
?>

I'd like to find something similar to display a CiviEvent registration page in Organic Groups without having to hard code a URL or mess around with a custom template.

I'm about to take a look at the API but would appreciate a short cut. Any ideas?

I think/I'm sure drupal as a tool to get the result of a menu url call.

If you can figure out what it is, add a &snippet=1 to the registration url, get the html generated by that, and display it, should work.

X+

> or load it via Ajax into any DOM element (slightly more complicated).

Careful with this. If you want this to work cross-browser, you will run into the usual csrf protection.

For the embedding, if it should work on IE7, you will need jsonp or the iframe + window.name transport trick.
json or xml will be blocked if it's cross-domain.
And be careful: Stuff you send via jsonp or iframe+window.name should never contain sensitive data or sensitive csrf tokens, etc.

The other issue is with ajax form submission.
QuickForm will add a csrf token to any form, and store a corresponding value in the session.
On submit, it expects the session cookie (sent via headers) and the token (sent via post), and both need to match.

By default, the browser will not send any cookie header from a remote site, so QuickForm will refuse to accept the form submission.
Modern browsers can be told to send cookies ("withCredentials") from trusted remote sites, but IE7 will not (i think this depends a bit on the configuration in internet options).

Also, you will have difficulties to submit the form via a standard jquery ajax post, if it is from a remote site.

There is a tricks about this. I don't remember if you need both or just one of them..
1. Instead of xhr post, you can create a hidden form, set the target to a hidden iframe, fill it with values and submit. I think there is a jquery plugin for that, but don't remember.. This trick is quite safe, because an attacker could do this anyway - so you don't open new doors.
2. You can give QuickForm a fake qfKey token. Just look where the token is generated, then it's quite obvious how to fake it.
HOWEVER, be aware that this will break any CSRF protection for this particular form. So, you should only ever consider this on forms where CSRF is not an issue.
The ideal thing is that you treat every form submission with a fake qfKey as if it was from an anonymous user. If anonymous cannot submit, then don't do this hack.

Nice article about CSRF:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

--------------------

The other option is iframe.
iframe allows form submission without leaving the page, and it is quite safe. The only threat would be clickjacking, and that is hard to deal with anyway.
The problem here is usually that the embedding site has less control about the appearance and behavior of the embedded form, again thanks to the same-origin policy.

To make your iframes more "customizable" by the remote site, you could
- Let the remote site specify urls to css and js files via GET parameters.
- Maintain some kind of whitelist, to decide which css or js is safe to include. Be careful - your trusted remote site could contain some user uploaded js and css files that are not safe at all. So, domain check is usually not enough.
- Send the iframe contents with the given js / css file added.

------------

The third option would be that you let the two servers talk to each other, before the pages are delivered. This will open some new possibilities, which I have not thought about much.
This is only an option if you have some control of both servers.