Cannot get module to work
edward.peters - October 9, 2008 - 08:49
| Project: | Redirect 403 to User Login |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
I have followed the installation instructions precisely but still get the message 'You are not authorized to access this page.' rather than the expected redirect to user log in page. Could there be incompatibility with another module? Or do I need to try anything else to tweak weight or other settings? Thanks for any help as this is an important module.

#1
You were right, it was just broken. There was no access callback set on the r4032login location, so it denied permission for anyone to view the redirect page. The new access callback will be in the next nightly tarball.
#2
Thanks so much! This is great now.
#3
... but, sorry, I find that it does not print the message "Access denied! You must login to view this page." I have made sure that the $messages variable is in the page-user.tpl.php file being used on that page. Any advice?
#4
separate issue, please re-file
#5
Automatically closed -- issue fixed for two weeks with no activity.
#6
The currently available 6.x-1.x-dev (2008-Oct-10) did not work for me, too. The "Access denied
You are not authorized to access this page." error still appears instead of redirecting to the login page :-(
Now I'm using LoginToboggan with the "Present login form on access denied (403)" option enabled, which works.
#7
I had this problem as well.
I had to manually set the custom 403 page to "r4032login" found under "admin/settings/error-reporting".
Shouldn't this be done automatically when the module is installed?
#8
I would just switch to the LoginToboggan module if you want a stable well-tested working solution.
#9
@lee20, I just committed enable and disable hooks to set and unset r4032login in 6.x. Others to follow. logintoboggan is a fine module as well if you want all the extra features.
#10
I don't need all the extra features - redirecting to login on 403 is actually the only feature I am using with LoginToboggan. I had to switch to it just because "Redirect 403 to User Login" did not work at all, and no response until now was given.
#11
#12
@roball you set r4032login the way readme.txt and #7 by lee20 say to and it doesn't work?
#13
I'm sorry deekayen, as mentioned I have uninstalled this module long time ago, so I didn't try if the workaround or your latest commit would fix the problem - but I believe you it would. I have a working alternative (released as a final version) on my production site, thus have no reason to once again try out a dev version.
Thank you for taking care about this anyway.
#14
Ok, I was just trying to clarify the status change, but it appears we're just stepping on each other's posts.
#15
Yeah, sorry the status change happened on accident after previewing my post - once I realized it, I changed it back accordingly.
#16
@deekayen - Thanks for this fix. I definitely prefer r4032login over logintoboggan. As you mentioned, when I have needed the additional features of logintoboggan I have used it (like autologin after register), otherwise I prefer to use this module to prevent the added bloat of the logintoboggan module.
#17
Now that I saw the dev version got a "final 1.0 release", I gave it a try again in order to replace LoginToboggan. Now on a 403 error the anonymous user will be redirected to "user/login?destination=r4032login", which includes the login screen properly. However, after logging in successfully, the user is redirected to "r4032login" which results in "Access denied.You are not authorized to access this page." :-(
Had to drop "Redirect 403 to User Login" again and switch back to LoginToboggan. That just works.
#18
roball: yeah. Bevan's patch was no good. Sounds like I'm rolling it back. #339120: Redirect issues
#19
6.x-1.0's Release notes "No known bugs." have been too optimistic...
#20
yeah yeah
#21
I rolled back #339120: Redirect issues. New releases should be out shortly.
#22
Automatically closed -- issue fixed for 2 weeks with no activity.