I have these modules enabled:

  • LoginToboggan (and I have enabled "Present login form on access denied (403)")
  • Custom Error
  • Custom error alternate for authenticated

Here is what is working so far:

  • Anonymous user attempts to access a restricted page
  • Login Toboggan jumps in and gives them a login form along with "Access denied"
  • user still doesn't have enough perms (has wrong role)

And this is what is happening but shouldn't be:

  • user gets ugly "Access denied" message

I think "Custom error alternate for authenticated" should be doing its thing here, displaying a nice message saying I need a higher role. But it isn't.

I'm pretty sure this is because Custom Error (and specifically, the "Custom error alternate for authenticated" module) is not playing well with Login Toboggan. Perhaps this issue should be cross-posted to that module, too... I'm not sure. I thought maybe the CustomError experts could take a stab at it first.

(And maybe this isn't really an error at all -- I suppose only one module can really officially handle 403 errors at a time. But I think it would be really great if LT could first handle it, and present the login form in the cool way that it does... followed by Custom Error jumping in and handling 403s for people who are already logged in.)

CommentFileSizeAuthor
#3 play_nicely_with-2382189-3.patch926 bytesdan3h

Comments

dan3h’s picture

An update: In the LoginToboggan config page (at admin/config/system/logintoboggan), if you set the "Present login form on access denied (403)" to "enabled", what it is really doing it setting changing the settings on the "Site Information" page (at admin/config/system/site-information), so that the "Default 403 (access denied) page" is set to "toboggan/denied". It has overwritten the "customerror/403", which was there before.

So maybe what is needed is a contrib-addon for Login Toboggan -- a way to that it could handle the initial 403, but then defer to the "Custom error alternate for authenticated" module (or any other module) if the user is already logged in.

Thoughts? Should I be posting this to Login Toboggan's issue queue?

gisle’s picture

Component: Code » Documentation

If LoginToBoggan replaces "customerror/403" with "toboggan/denied", then CustomError will not get into the error handling loop at all. To me, it looks like these two modules are currently incompatible, as they compete for the setting the system path for the 403 error handler.

To me, it looks as if this have to be solved by changing LoginToBoggan, since this module insists on handling all 403 errors.

I am not by any means familiar with LoginToBoggan, but one way to resolve this is to have LoginToBoggan check and see if CustomError is enabled, and if it is enabled, and the user is logged in, then it should invoke drupal_goto and send the user to "customerror/403" for handling the error. Maybe you want to post this as a feature request in the LoginToBoggan issue queue?

Thank you for digging into this. I don't think it can be resolved by changing the code of CustomError (since LoginToBoggan effectively locks it out). However, until this incompatibility is resolved, it should be documented, so I am changing component.

dan3h’s picture

StatusFileSize
new926 bytes

Thanks for the prompt reply, @gisle. I dug a bit deeper, and I have a solution! Basically, it involves overriding Login Toboggan's theme function, for 403 messages, theme_lt_access_denied().

But first, it requires a small refactoring of the Custom Error module. Basically, we need to have the option to be able to call the customerror_page() function directly and pass our error-code in to it, rather than having to pull the error-code out of arg(1). See my attached patch, which accomplishes this.

Then, you just need this:

function MYTHEME_lt_access_denied() {
  return customerror_page(403);
}
dan3h’s picture

If the patch from #3 is already applied to CustomError, then here is how you can override the theme function in a custom module:

/**
 * Implements hook_theme_registry_alter()
 */
function MYMODULE_theme_registry_alter(&$theme_registry) {
  if (module_exists('logintoboggan')) {
    $theme_registry['lt_access_denied']['theme path'] = drupal_get_path('module', 'MYMODULE');
    $theme_registry['lt_access_denied']['function'] = '_MYMODULE__theme_lt_access_denied';
  }
}

/*
 * Theme function for Login Toboggan's 'lt_access_denied'.
 */
function _MYMODULE__theme_lt_access_denied() {
  return customerror_page(403);
}

And of course, that lends itself to the possibility of this being bundled right in the CustomError module:


/**
 * Implements hook_theme_registry_alter()
 */
function customerror_theme_registry_alter(&$theme_registry) {
  if (module_exists('logintoboggan')) {
    $theme_registry['lt_access_denied']['theme path'] = drupal_get_path('module', 'customerror');
    $theme_registry['lt_access_denied']['function'] = '_customerror__theme_lt_access_denied';
  }
}

/*
 * Theme function for Login Toboggan's 'lt_access_denied'.
 */
function _customerror__theme_lt_access_denied() {
  return customerror_page(403);
}

It could also be broken out into another contrib-module that could be bundled with CustomError: Something like "CustomError-LoginToboggan integration".

dan3h’s picture

Component: Documentation » Code
Category: Bug report » Feature request

Switching this back to a code feature-request, as I'd like to get my patch from #3 incorporated, so that my solutions in #3 and #4 will work. I think that the patch is actually an improvement to the code (slightly better style).

gisle’s picture

Version: 7.x-1.3 » 7.x-1.x-dev
Status: Active » Needs review

Thanks for the patch dan3h!

The patch in #3 as well as the hook_theme_registry_alter() from #4 has been added to the latest dev snapshot.

Your code look fine and I agree that it is better style.

However, I will wait for someone else who is familiar with LoginToboggan to post a review here before before committing to a tagged release.

  • gisle committed a299a59 on 7.x-1.x
    Issue #2382189 by gisle: Changed README.txt to have a section about...
dan3h’s picture

Thanks, Gisle! Very glad to help.

A couple more comments on this:

* LoginToboggan[1]:
When this module is enabled, CustoMerror will override
LoginToboggan's theme function for access denied pages so that you
can use CustomError and Custom error alternate for authenticated
to handle the error.

This is not entirely accurate. It should be something more like this:

* LoginToboggan[1]:
Our "Custom Error Alternate for Authenticated" module normally takes over handling the system "Default 403 (access denied) page". But if LoginToboggan is enabled, and if its "Present login form on access denied (403)" config option is enabled, then LoginToboggan will take control of the 403 messages, instead of Custom Error Alternate for Authenticated.

Also, the patch in #3 actually has nothing to do with Login Toboggan -- it simply allows other modules or theme functions to be able to call customerror_page() directly, should they want to. It should be ok to release, as-is.

The change I suggested in the bottom half of #4 is the one that might benefit from some Login Toboggan eyes.

gisle’s picture

dan3h, you suggest that the new section of README.txt where I explain how CustomError behaves after incorporating the patch #4 in CustomError should be:

* LoginToboggan[1]:
Our "Custom Error Alternate for Authenticated" module normally takes over handling the system "Default 403 (access denied) page". But if LoginToboggan is enabled, and if its "Present login form on access denied (403)" config option is enabled, then LoginToboggan will take control of the 403 messages, instead of Custom Error Alternate for Authenticated."

I am not sure I understand this. I thought the whole point of the patch in #4 was to override the LoginToboggan theme function to allow CustomError and CustomError alternate for authenticated to handle the error.

To me, it looks like your text explains what happens if patch #4 is not incorporated in CustomError. Please clarify this.

dan3h’s picture

Sorry for the confusion! I read too quickly, and thought you had only committed my patch in #3, but now I see that you also included the changes that I had suggested from #4.

Now your change to the README makes a lot more sense. But I'd still alter it a little, partly based on a little more that I've understood about how this module and LoginToboggan both handle 403 errors (and how they can conflict). I'd put something like this (feel free to edit/reword it):

If LoginToboggan is enabled, in can enhance CustomError's handling of access-denied messages, but you have to be careful to set them up to work together correctly.

These two modules both attempt to take over handling of system 403 ("access denied") messages, and can conflict. CustomError does it by asking you to go to "admin/config/system/site-information" and manually setting the "Default 403 (access denied) page" to "customerror/403", whereas LoginToboggan sets that same field to "toboggan/denied" automatically (overwriting any other value that was there), when you enable its "Present login form on access denied (403)".

If you are using CustomError with LoginToboggan, you should allow LoginToboggan to perform this take-over (in other words, DON'T set the "Default 403 (access denied) page" to "customerror/403"). This way, if someone attempts to access a page that they don't have access to, LoginToboggan will first give them a chance to log in if they haven't yet. If they *still* don't have access to the page, CustomError then takes over from LoginToboggan (by overriding one of its theme functions), displaying its customisable messages for access-denied errors.

  • gisle committed df32601 on 7.x-1.x authored by dan3h
    Issue #2382189 by dan3h: Changed README.txt to explain how to make it...
gisle’s picture

Version: 7.x-1.x-dev » 7.x-1.4
Assigned: Unassigned » gisle
Status: Needs review » Fixed

This has now been committed to release 7.x-1.4.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.