Auto approve requested invite based on referer

So far so good, #1 and #2 are in and working in my test version. Even if you aren't using this for access control, I think it's useful to capture referrer as it helps track where an invite request came from.

Thanks, will do. I already wrote that part to do hook_update_n so we're on the same page. Here's what the field looks like at the moment, plus the addition to the schema.

/**
 * Update requestinvitation table to have the referer field.
 * @see http://drupal.org/node/1099652
 */
function requestinvitation_update_6100() {
  $ret = array();

  db_add_field($ret, 'requestinvitation', 'referer', array(
      'description' => 'HTTP referer when invite was requested',
      'type' => 'varchar',
      'length' => 2048,
      'not null' => TRUE,
      'default' => '',
    )
  );

  return $ret;
}

OK, here we go. I made quite a number of changes, against the existing 6.x-1.x-dev tree as checked out from git. Here's what I did.

1) Fixed bug where this module would set the invite_subject_editable to true, regardless of what you had it set to in the invite module. This was breaking my site because I don't want my subjects to be editable and it overwrites what is set in the invite module.

2) Extended the requestinvitation.install to add a new column to the database table. This will store the HTTP referer from the page where the request invitation was submitted. Also added this as an update function for existing users of the module.

3) Extended the requestinvitation.module to capture referer on the form.

4) Visually display an error if the request does not make it into the database (the INSERT fails.)

5) Cleaned up a few things per the coder module, including adding check_plain in a few places where it recommended them.

6) Add another validation step to check if the user already has an account on the site.

7) Add another validation check on the email address if the email_verify module is enabled. If the module is enabled, it checks the submitted email address against it. If not, the check is never performed.

8) Added watchdog logging when the form_validate function fails.

9) Added a new variable for what path to redirect users to after the form submit. In my case, they can't get to the default 'requestinvitation' path since I use this in a block and don't allow access to that path. You can now specify this in the UI.

10) Fixed a php 5.3 warning with module_invoke() and call time references. This is actually more of a workaround than a fix.

Now the fun part - this all works well unless you are using Varnish or another reverse/caching proxy. You will also need to implement a 'no cache' policy on the whitelisted invite sites, or else the page will be cached and you won't see the right referer at the Drupal level. In varnish land, this looks like the following configuration directive, near the top of my sub vcl_recv{} in varnish.vcl:

  // Requestinvite: Do not cache if the referer comes from a site on the invite whitelist
  if (req.http.referer ~ "^http://whitelistedsite.com/") {
    return(pass);
  }

You could always get fancy and not cache any external redirects, but in my case I don't have a lot of whitelist hosts so it's easier to do an include vs an exclude.

I'm in production with this code now and it's working for me. If I run into any bugs I'll post it back to this issue.

Quick update on #5. This is now working, and fairly well. The referer is correct about 80-90% of the time, although some folks may come from places like Google Reader or other sites. Not a big deal to manually approve them.

You could also add * as the referer, and then simply use this module as a part of the registration system. The way I have this working is a front-end requestinvite with the user's email address, then an auto-approved requestinvitation email is sent with the invite link, and the users get immediate access after completing the regform.

That's a more natural process IMO than the default Drupal approval process. In that case it's fill out a complete registration form, then go to your email to validate your address, then start using the site. It's subtle but I think the flow for the user is better if you get the email validation out of the way up-front.