If the user is anonymous, then the user will be presented with the login page 'user/login' instead of a the 403 default page. If the user then logins in and has access to the page they will then get redirected to the page they were trying to access. If the user is already logged in then they will get the defined 403 page.

With the standard system you cannot just set user/login as the 403 page as you will not be redirected to the page that you were originally requesting, but instead to the user page.

Comments

gordon’s picture

gordon’s picture

StatusFileSize
new3.43 KB

here is a newer version of the patch which adds an option to admin/settings page so this functionality can be turned off and on.

moshe weitzman’s picture

I have been wanting this since i first saw drupal (i.e. a long time). +1

dries’s picture

Because the 403 page is configurable, this is already possible. This patch only makes it more convenient. I tempted to say: "Won't commit, but let's extend the form description a bit so it is clear this is possible.". That or we add a link to the login page (without the extra setting), cfr. to what the comment module does.

moshe weitzman’s picture

dries - upon executing the 403 handler, the original $_GET['q'] is lost. That means that we cannot redirect to the destination page after login and thats one of the main benefits of this patch.

gordon’s picture

Yes you can use the user/login link, but once you login you get the user page and not the page you were triing to get to. Also if you are logged in you will still get the user/login page when really you should get the custom access denied page.

slower’s picture

What version of Drupal is this for? I'm using 4.5.

gordon’s picture

It is for cvs (4.7) I would have to rewrite it if I was to port it back to 4.5

gordon’s picture

Dries, What is the verdict on this patch.

I have found no way of prompting anonymous users to login and continue seemlessly without this patch. Please correct me if I am wrong, as this is some functionality that I require.

neofactor’s picture

Glad to see it...

I had always just added the following custom pages:
http://neofactor.com/error403 (with a login link)
http://neofactor.com/error404 (Adding the auto search)

My 403's are only for non-members and all members have the same access.
I use PHP to control groups differently for lots of different clients, so this works out well form me.

The auto redirect function is nice.... keeping the user's initial request in place.

hey.... When is Drupal going to add images to pages at core? Visual appeal.... It would be great if menu items and other areas started to do this... then people could just swap them out. Just a wish list.

;)

gordon’s picture

Just adding the pages does work, but does not give the effect that I need. You can always use the login box on the sidebar, which will do the same thing.

You said that the 403's aren't used to logged in users as they have the same privledge, But not everyone has the same privledge on your site (unless everyone has the same rights as user 1 ;-))

So what if a user who is already logged in goes to /admin you do not want to tell them that they need to login to get to the admin page, you want to send them to a big go away page.

jjeff’s picture

Before I saw this thread, I posted another take on this bug at http://drupal.org/node/26659. It explains the problem a little more in-depth.

Here's the thing: What makes Drupal sites look like Drupal sites is that they've got a login/password box on every page until the user is logged in. For Drupal to become a mature platform, it's going to need to move away from dependence on this crutch. Drupal should provide the infrastructure to allow the option of a simple "Login/Register" link.

However, if a user gets an access denied message, they should be prompted to log in.

As it is, the best that you can do after login is direct them back to the node that defines the "Access Denied" message. This is more than just confusing for the user. It's downright wrong!

Dries, please reconsider this patch and/or some variation that solves this problem. It is essential for all current versions of Drupal.

Thanks,
Jeff

Kobus’s picture

In concept, a definitive +1 from me. Especially the mention that the login box does not even display unless the user has to log in. I have started to remove the block completely and put it in a menu somewhere else so that it is not so obtrusive. For a commercial site, the exaggerated login page makes it look "as if you have something to hide". Not good.

Regards,

Steven’s picture

You say you can't use a custom 403 page because it doesn't know where it came from... so, why not set a destination parameter instead? I think all that needs to be done is set $_REQUEST['destination'] = $_GET['q'] before calling menu_set_active_item() in drupal_access_denied(). Probably the same for drupal_not_found().

The destination is then picked up by the login-block which adds destination=drupal_get_destination() in the form's action.

gordon’s picture

The login block already picks up the correct page. but there are some people who do not want to have a login block on the site, but use a link to the login page to allow a user to login.

Also having getting users to enter in PHP code to solve this problem IMO makes Drupal very unfriendly (in this area) as it will require the admin to know a lot more about PHP than they should need to.

I have still not been able to user standard configuration options to achieve this.

willmoy’s picture

If we implement an option for user/login, it's going to be reasonable for someone to request an option for user/register (please register to gain access to premium content/full articles/whatever). Same again for a dual login/register page.

I'm working on a site with most content behind the login, and I've been struck by how unenticing user/login and user/register are anyway. Perhaps adding to the handbook a selection of nicely done, helpful custom 403s (that maybe tie in to drupal themes) with a good explanation of how to use them would provide the functionality and help people make more attractive sites. The form description could include a link.

The custom 403 on that site shows 'You do not have permission to view this page' if the visitor is logged in or 'You need to log in' if it's an anonymous visitor. If they log in, they are sent straight to whatever page they wanted in the first place. I'd paste it here, but it wouldn't survive the input check. More than happy to share it, though.

tangent’s picture

StatusFileSize
new1.82 KB

I also agree that this behavior is sorely needed. I made several failed attempts at using custom php in a node and the customerror module before deciding that this should REALLY be in core anyway.

Attached is the patch I made before coming here to do a search. It probably has some issues since I'm not very versed in how Drupal works at this stage but one difference from that of the original poster is that it only sends a 403 header if the user is actually getting a 403 message. In my opinion, the login form should not send a 403 in the case that a login form is displayed.

Please consider one of these patches for 4.7 as this behavior would be a needed addition.

kbahey’s picture

How does this integrate with custom 403 error pages (whether using customerror module or a normal Drupal node)?

I like this new proposed functionality, but also want it with a custom error page where I can put links to search, site map, login, ...etc..

tangent’s picture

My preference would be for guests to receive a login form and for authenticated users to receive either the custom 403 message or, failing that, the standard message.

The custom message is simply a way of overriding the default message while the login form is something else and should override ANY message for guests.

tangent’s picture

It seems I'm not having any luck gathering interest in this issue. Has anyone found an problems with the patch? If not I'll mark it ready to commit as it's obviously a desired fix by virtually all commenters.

Wesley Tanaka’s picture

StatusFileSize
new1.26 KB

Original patch modified to work against 4.6.3. and with a more friendly title

kbahey’s picture

Side comment on the same functionality:

I have implemented something similar using the customerror module.

See this issue http://drupal.org/node/35687

Basically, it requires a one line change to common.inc to save $_GET['q'] in the $_SESSION, then customerror checks for that in a customererror_login() hook, and redirects to the saved destination.

The line is:

$_SESSION['destination'] = $_GET['q'];

And should be added after the line with :

watchdog('access denied' ...

Wesley Tanaka’s picture

StatusFileSize
new613 bytes

The problem I'm having with this approach (at least on my install of drupal) is that something about drupal's default page caching behavior, in combination with firefox, at least, is causing the login page to get cached for the URL. So when I try to log in from the page, I authenticate properly, but I end up viewing the cached "access denied" page. I've decided to switch back to the previous way my site handled this (before Drupal) and redirect the user to the login page when they hit an access denied page (and are not logged in). Patch (on top of my previous patch) attached.

Tobias Maier’s picture

i hope i can disable this feature because I dont want that the visitors can see that I am using a cms to maintain the page...
(question of security)

personally I would like it if you are using customerror (the errorpage is themeable so you can include every code you want...)

kbahey’s picture

I just added a patch and pre-patched version for common.inc in the issue mentioned above in #22.

It makes taking advantage of the remembered redirection much easier, now that patches and a pre-patched version of common.inc are included.

drumm’s picture

Status: Needs review » Needs work

Please flatten the patch on a patch into a single patch.

klance’s picture

Hmm... in my php template, I just did this:

if( $title == "Access denied" ) {
  echo "<a href=\"/en/user?destination=" . substr( $_SERVER['REQUEST_URI'], 1 ) . "\"><b>Please click here to log in</b></a>";
} else {
  // don't display the rest of Access denied message (you are not authorized to blah, blah...)
  if( $content ) { print $content; }
}
lilou’s picture

Title: Allow annoymous users to log in on access denied » Allow anoymous users to log in on access denied
Version: x.y.z » 7.x-dev
sun’s picture

Status: Fixed » Closed (fixed)

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