views:

487

answers:

3

This may well be simple, but I'm new to Drupal. The organization I work for switched to Drupal a little while ago, but there's still some legacy code in various external PHP files that would be cumbersome to convert over to work within Drupal.

However, it would be very nice to be able to restrict access to some of these pages based on a person being authenticated against Drupal. (Some pages are administrative and are currently visible to anyone who knows the URL, for instance. Yes, poor design, but that's what I inherited...)

How can I check with Drupal, from an external PHP file, to see if the person visiting a given page has authenticated?

+4  A: 

You'd need to include those URLs in the menu router so Drupal can bootstrap and check your permissions. Then you'd need to find away to run your third party PHP as an include file or maybe through an interface.

Some clever custom work is required but possibly not too hard. :)

Rimian
This seems like a good approach. You could put all of the third party files into a module.
Jeremy French
This could work, but the code I'm working with does its own form submission handling—I'd have to convert that over to work with Drupal, yes?
peppergrower
Probably not. There's nothing to stop you rendering a third party form in your page and/or running code that would handle $_POST or $_GET. Drupal would ignore it.
Rimian
A: 

Drupal stores the the user authentication in the session. However it uses it own custom session handling (see includes/bootstrap.inc where it attaches the custom handlers and includes/session.inc for the callback functions). If you use the same session handling function you could access the Drupal session data to see if the user is authenticated.

grom
Sound like a lot of work duplicating functionality that already exists.
Rimian
+3  A: 

I would go with Rimians suggestion of registering the URLs within Drupal itself (+1), but as an alternative, you can bootstrap Drupal 'manually' and check a user permission after that directly from other scripts as well:

// initialize Drupal
// TODO: adjust path according to placement of script (might need to change to Drupal directory first)
require './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
// check user access rights
// TODO: Adjust to the permission you want to restrict to, e.g. 'access content' or whatever
if (!user_access('administer nodes')) {
  // Insufficient rights, say so
  drupal_access_denied();
  exit(0);
}
// ... call legacy script

NOTE: Drupal does quite a bit of work during bootstrap, including some manipulation and setting of global variables, so make sure to check carefully for interferences/clashes with the legacy code (would also apply for Rimians suggestion).

If you want to restrict access to authenticated users only, you can replace the user_access() call with user_is_logged_in(). If you want to check by role, you can add a global $user; and check the contents of the $user->roles array

Henrik Opel
I like this solution, and I seem to be close to getting it working...I'm getting Drupal to bootstrap, but the global `$user` has a `uid` of 0, and the role `anonymous user`, etc. Any ideas why it's not getting populated with my real user role information? Is there another Drupal function I need to call to get the real session info in there? (I'm running Drupal 6.12, if that matters.)
peppergrower
Update: checking my cookies, I now have two session cookies (one of which is for an authenticated user, and one of which is for an anonymous user). How can I get Drupal to use the old session and not create a new one?
peppergrower
@peppergrower: This would normally happen only if the script got called under a different domain than your normal Drupal install (causing the browser to *not* use the same cookie). If the difference is only on the third level of the domain (e.g. 'drupal.example.com' vs. 'legacy.example.com'), you can work around this by setting the `$cookie_domain` in settings.php to the common second level, thus forcing usage of the same cookie. If the second level domain differs as well, your out of luck and would need to ensure a separate login on the other domain.
Henrik Opel