The Message for Request Password Reset form, which appears inside the HTML Login form group box in admin/settings/securesite, is not just used when you select Enabled with HTML login form, but also when you select Enabled with web browser HTTP-AUTH security, namely when the user clicks the [Cancel] button on the dialog. So I guess that second textarea shouldn't be inside the HTML Login form group box. That's more of a cosmetic issue, however...

If you take advantage of the offer to clear the textarea to not process password resets through this module, and the user clicks the [Cancel] button on the HTTPAUTH dialog, then he gets a page that has nothing but an empty rectangle.

IMHO, clicking the [Cancel] button in this case should lead the user back to / -- here we're close to http://drupal.org/node/103268 again, which is still open...

Comments

NaX’s picture

NaX commented

This sounds a little like themeing issue. You are correct. When the user clicks cancel something should be displayed to the user and the most logical thing for me is a password reset feature incase the user is having login problems.

Their is a way to theme the html dialog without hacking. In the HEAD and 5.x-1.x-dev version of secures site is a file called dialog.tpl.php. If you rename this file to securesite-dialog.tpl.php and place it in your default theme directory it will be used by securesite. This way you can override the out put of the html form. The only requirement is that you somewhere print out the $content variable, unless you don't want to use the securesite html forms.

I realized after committing it to head that dialog.tpl.php is the wrong file name and it should be renamed. It has not been committed to 4.7 as its usage has not been documented yet.

You can also use this file to redirect the user. You cant use php (drupal_goto()) to redirect the user as you then never see the auth dialog, but you can use JavaScript with a onload function.

When it comes to redirecting a user back to "/" on cancel, this is proving to be a little more difficult. The html login form does this just fine but it is not that simple with http-auth. I had a good look at it early in December and did not find a reasonable solution, when I have some more free time I will see if I can find a workable solution.

salvis’s picture

salvis
he/his
commented
Version: master » 4.7.x-1.x-dev

The new HEAD doesn't seem to work with Drupal 4.7.* anymore, so I've changed the version number here.

This sounds a little like themeing issue. You are correct. When the user clicks cancel something should be displayed to the user and the most logical thing for me is a password reset feature incase the user is having login problems.

I agree with you that it's a reasonable thing to do, if the user is allowing securesite to handle the password reset. However, you specifically write "Leave [Message for Request Password Reset form] empty to not process password resets through this module", and if I do that, then the password reset form should not appear — that's more than just a theming issue...

Their is a way to theme the html dialog without hacking. In the HEAD and 5.x-1.x-dev version of secures site is a file called dialog.tpl.php. If you rename this file to securesite-dialog.tpl.php and place it in your default theme directory it will be used by securesite. This way you can override the out put of the html form. The only requirement is that you somewhere print out the $content variable, unless you don't want to use the securesite html forms.

I realized after committing it to head that dialog.tpl.php is the wrong file name and it should be renamed. It has not been committed to 4.7 as its usage has not been documented yet.

But it doesn't work with 4.7.5, does it? I copied securesite.dialog.tpl.php to httpdocs/themes as well as to httpdocs/sites/example.com/themes, but it didn't make any difference.

You can also use this file to redirect the user. You cant use php (drupal_goto()) to redirect the user as you then never see the auth dialog, but you can use JavaScript with a onload function.

What about the other methods of redirecting, either

  header( 'Location: http://' . $_SERVER['HTTP_HOST'] . '/' ) ;
  exit;

at the top of the file, or

<meta http-equiv="refresh" content="0;url=/">

inside the <head> element?

When it comes to redirecting a user back to "/" on cancel, this is proving to be a little more difficult. The html login form does this just fine but it is not that simple with http-auth. I had a good look at it early in December and did not find a reasonable solution, when I have some more free time I will see if I can find a workable solution.

Have you tried all of the above redirection methods? I wish I could get 4.7.5 to use the theme template...


Since I updated to 4.7.5 I'm not just getting an empty rectangle, but also a bunch of error messages:

Warning: array_keys() [function.array-keys]: The first argument should be an array in .../modules/user.module on line 352

Warning: implode() [function.implode]: Bad arguments. in .../modules/user.module on line 352

Warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 query: SELECT DISTINCT(p.perm) FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in .../includes/database.mysql.inc on line 121
NaX’s picture

NaX commented

About the themeing file. Let me explain a little better. I you use the securesite-dialog.tpl.php file that comes with securesite it will look and function exactly the same as if you did not use the file. The securesite-dialog.tpl.php file is for custom themeing. You can use the tpl file to make securesite match your own theme.

To use securesite-dialog.tpl.php you need to place it in your default theme directory. EG. "drupal-4.7.5\themes\bluemarine\securesite-dialog.tpl.php".

Because you are having problem I check that it works by copying the securesite-dialog.tpl.php file into my default theme on my test site and then edited the file. I removed all the contents of the file and the just had "hello world" at the top of the file then I logged out, clicked cancel when the auth dialog came up and then all had on my screen was the words hello world.

When it comes to the redirect. You cant use a php redirect ( header( 'Location: ....;) as it redirect before showing the user the auth dialog. This very important as the only way to reset the auth variables is to show the auth dialog again. After the user clicks cancel then we can try to redirect.

I tried the meta refresh method by putting <meta http-equiv=refresh content='0; url=http://www.google.com'> in my securesite-dialog.tpl.php, and when I clicked cancel I ended up at google, I think this could work for you if you want to use http-auth.

I would maybe also consider using some kind of JavaScript that comes telling the use they will be redirect home in 5sec and a link back to home if JavaScript is not enabled.

If http-auth is not a requirement I would recommend using the html login form. If you are using rss feeds then http-auth would be required.

When it comes to your problems have you tried "Reset to defaults" on the securesite settings page. I a have tested the module on 4.7.5 and it does not give me any errors. I did this test on a fresh install and not from an upgrade. Maybe something went wrong with the upgrade.

Lastly I tested the leaving the Message for Request Password Reset form blank and it worked. The Password Rest form did not come up. Only the html login form if I had it set to html login form. If I set it to http-auth then I get the gray empty block you described. What is the problem here?

salvis’s picture

salvis
he/his
commented

To use securesite-dialog.tpl.php you need to place it in your default theme directory. EG. "drupal-4.7.5\themes\bluemarine\securesite-dialog.tpl.php".

Oh, ok! I misinterpreted the term "default theme directory" as default theme-directory rather than default-theme directory and put the file into the wrong places. Your example helped and it works now.

When it comes to the redirect. You cant use a php redirect ( header( 'Location: ....;) as it redirect before showing the user the auth dialog. This very important as the only way to reset the auth variables is to show the auth dialog again. After the user clicks cancel then we can try to redirect.

I'm not sure whether I care about resetting the auth variables (I know that others do care), but it turns out that the PHP redirect disables securesite completely, i.e. it never shows the dialog anymore.

I tried the meta refresh method by putting in my securesite-dialog.tpl.php, and when I clicked cancel I ended up at google, I think this could work for you if you want to use http-auth.

Yes, indeed, this works, but the page with the empty block (and the error messages) still shows up briefly, even with a 0 delay.

I would maybe also consider using some kind of JavaScript that comes telling the use they will be redirect home in 5sec and a link back to home if JavaScript is not enabled.

Yes,

<body onload="window.location.href = '/'">

works, too, if JavaScript is enabled, and it takes precedence over the meta redirect, but the browser still briefly shows the page we're trying to bypass.
I don't see why you'd want to delay for five seconds — to admire the empty block? The link back to home inside a <noscript> element is a good idea though.

If http-auth is not a requirement I would recommend using the html login form. If you are using rss feeds then http-auth would be required.

Exactly, that's why I need http-auth.

When it comes to your problems have you tried "Reset to defaults" on the securesite settings page. I a have tested the module on 4.7.5 and it does not give me any errors. I did this test on a fresh install and not from an upgrade. Maybe something went wrong with the upgrade.

"Reset to defaults" (and re-setting my settings) hasn't made a difference. I only get the errors if I hit [Cancel] after clicking the "log off" link. Clicking [Cancel] when the dialog is displayed for the purpose of logging in, doesn't produce the error messages, only the empty rectangle. But this won't matter if we can solve the primary issue...

Lastly I tested the leaving the Message for Request Password Reset form blank and it worked. The Password Rest form did not come up. Only the html login form if I had it set to html login form. If I set it to http-auth then I get the gray empty block you described. What is the problem here?

The problem is the empty block (under the Pushbutton theme it's interior is white, so it's just a black empty rectangle). What should the user do with an empty block? That's the point where I started: it is reasonable to go to the Password Reset form when the user cancels the dialog, but if the admin has disabled the Password Reset form, then it's not reasonable to go to an empty block.

That's why I would have liked to redirect to / instead of leaving the user at the empty block. That's the logout behavior without securesite, and if securesite is only used for making RSS feeds available, then it shouldn't change the behavior of the site for normal interactive users.

Let me take a step back: Can you tell whether the user logged in via HTTPAUTH or via the Drupal login form? In the second case (that's the one I'm concerned about), no HTTPAUTH variables were set, and so there is no need to display the dialog to clear them, so securesite wouldn't need to interfere during logout at all.

Thank you for your help and patience!

salvis’s picture

salvis
he/his
commented

A minute after submitting my reply I had yet another idea:

<body onload="window.location.href = '/'" style="display: none">

This effectively suppresses the display of the empty block (and error messages if any)!
Combined with the meta refresh, it will redirect most users to home, and those that have both JavaScript and meta refresh disabled, will be left with a completely empty page. That's better IMO than the rectangle.

But the question at the end of the previous message still stands: couldn't securesite just step out of the way if it doesn't need to reset the HTTPAUTH variables?

NaX’s picture

NaX commented

I think you missing one of the key points of the securesite-dialog.tpl.php. You have full control of what happens here.
Try this for your securesite-dialog.tpl.php.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<meta http-equiv=refresh content='1; url=http://www.example.com'>
<head>
<title><?php print variable_get('site_name', 'drupal'); ?></title>
</head>
<body>
    Redirecting back to home.
</body>
</html>

By removing the print $content; it should not show any errors and even if you have set securesite to using the password reset form, it will not come up. By removing the div's and the styles the gray block will also not come up.

salvis’s picture

salvis
he/his
commented

I think you missing one of the key points of the securesite-dialog.tpl.php.

That may well be true, but what makes you say that? display: none, along with meta refresh and JavaScript redirect, comes closest to what I need so far.

Your code (the meta element belongs inside the head element) briefly displays "Redirecting back to home", followed by the error messages, before redirecting. In what way would your code be better?

It would still be desirable to suppress the display of the dialog altogether, when no HTTPAUTH variables need resetting. If there was a suitable test, we could do a PHP header() redirect...

In fact, I've finally found my solution:

if ( drupal_get_destination() == 'destination=logout' ) {
  header( 'Location: http://' . $_SERVER['HTTP_HOST'] . '/' ) ;
  exit;
}

at the top of securesite-dialog.tpl.php. I use securesite only for making feeds available, and no browser user needs to log in via securesite, so it's not necessary to remove the HTTPAUTH variables, because they're not set on my site.

This will not work for everyone. of course. If you could tell whether the HTTPAUTH variables are set or not, you could use a more specific condition.

NaX’s picture

NaX commented

In that case I recommend you using the drupal_goto() function. By calling a empty drupal_goto it takes you back to the homepage.

drupal_goto();

I would recommend trying to find out where those errors are coming from, that is not normal.
I also recommend using the latest version of securesite. Their have been some small improvements recently.

salvis’s picture

salvis
he/his
commented

In that case I recommend you using the drupal_goto() function. By calling a empty drupal_goto it takes you back to the homepage.

Yes, that works nicely, thank you.

I would recommend trying to find out where those errors are coming from, that is not normal.

It seems to be an interaction between securesite and the devel module (after updating Drupal to 4.7.5), and it happens after clicking the [Cancel] button: user_access() is called by devel_exit() with $account==NULL (by default) at a point where $user is NULL, too, and subsequently the array_keys() call in user_access() is in error.

I also recommend using the latest version of securesite. Their have been some small improvements recently.

It's funny, you've put the hook_use() spelling error in the comment back in, but other than that I already had the current 4.7.x code.

Forgive me for being a pain, but you're still ditching my question whether you can tell whether the user logged in via Drupal or securesite...

NaX’s picture

NaX commented

Forgive me for being a pain, but you're still ditching my question whether you can tell whether the user logged in via Drupal or securesite...

No, at the moment we cant tell were the user was logged in from. Why is their something you would like to do with that information?

If the user is already logged in and the http-auth dialog is displaying then their might be a permissions problem. Make sure that your users have the securesite permission "access site". If the users is already logged in and has all the necessary permissions then the auth dialog should not come up, unless something else is wrong.

salvis’s picture

salvis
he/his
commented

If the user is already logged in and the http-auth dialog is displaying then their might be a permissions problem. Make sure that your users have the securesite permission "access site". If the users is already logged in and has all the necessary permissions then the auth dialog should not come up, unless something else is wrong.

I'm looking at the log out stage, not the log in stage. Let me try to explain myself step by step:

  1. We agreed before that when the user clicks "log out", it would be desirable to not display the dialog at all, right?
  2. But you explained to me that securesite needed to display it to clear the HTTPAUTH variables in the browser, right?
  3. If securesite were smart enough to know how the user logged it, it could customize the log out process accordingly; specifically, if the user logged in via plain Drupal, no HTTPAUTH variables need to be cleared and securesite wouldn't need to display the auth dialog in that case, right?

This would provide a more consistent user experience:

  • those that log in via Drupal could also log out via Drupal without ever seeing anything related to securesite;
  • those that log in via securesite will more easily accept seeing the dialog again when they log out, because they've already seen it before.

Right now, you're unnecessarily forcing the dialog on the former group as well — it surprises and confuses them.

NaX’s picture

NaX commented

Originally I tried to implement a way that would do what you described, but I ran into problems with storing the information as when a user clicks logout the session is destroyed before hook_user is called.

Another problem was that how do I know the user has typed in something different. As the PHP-AUTH variables have not been reset how do I know the user is try to login again. How do I know if he is trying to login with the same details or different details. As I don't have control over the dialog I cant set any hidden fields like it would be for a form, making it possible to tell if the user is trying to re-login.

I tried for a while to create a work around but in the end I abandoned the idea and rather focused on other features like the bypass filter pages.

salvis’s picture

salvis
he/his
commented

Originally I tried to implement a way that would do what you described, but I ran into problems with storing the information as when a user clicks logout the session is destroyed before hook_user is called.

So, you can't record the log out action. But we have to do without that information anyway, because the user might also just close the browser without logging out.

Another problem was that how do I know the user has typed in something different. As the PHP-AUTH variables have not been reset how do I know the user is try to login again. How do I know if he is trying to login with the same details or different details.

I must admit I don't understand exactly how HTTPAUTH works and how securesite interacts with Drupal and HTTPAUTH, and I don't understand your questions, probably because I don't have the proper context. Maybe these ideas help:

  • You can recognize a log out attempt when drupal_get_destination() == 'destination=logout'; any other destination is a log in attempt, whether with the same or with different credentials.
  • Drupal records the time of the last log in for each user. So, if that time is within a minute of securesite displaying the dialog, it's reasonable (not certain, but likely enough IMO) to assume that the user logged in through the dialog, i.e. securesite should redisplay the dialog at log out time.
  • If securesite has never displayed the dialog before, it shouldn't ever display it at log out time either.
  • When securesite displays the dialog for logging in, one of several things can happen:
    • the user logs in successfully
    • the user types wrong credentials (then the dialog comes up again, so we can probably ignore that case)
    • the user clicks [Cancel]
    • the session is abandoned, i.e. nothing happens anymore

    Can you positively detect and record any of these events? Can you record the time of Drupal log-in independently of Drupal?

  • If securesite is used for accessing RSS feeds, then things are a bit more complicated: the feed reader may log in to access the feed every hour, and the browser may come and go at any time. Is there a concept of session, i.e. is there a way to tell, that the last HTTPAUTH log in was not part of the browser session that the user is logging out from?

To avoid turning in circles I'll try to address your direct questions:

Another problem was that how do I know the user has typed in something different.

What do you mean with "something different"? You mean logged out of one account and in to a different account? I don't think that's possible with securesite at all. If the user clicks "log out" and securesite displays the dialog, it doesn't seem possible to log in again — securesite will continually redisplay the dialog, presumably because the user tries to "log in" to /logout .

As the PHP-AUTH variables have not been reset how do I know the user is try to login again.

"PHP-AUTH variables"? I don't know what those are. Did you mean the HTTPAUTH variables in the browser?

How do I know if he is trying to login with the same details or different details.

Why does this make a difference? How can we get into a situation where that's an issue?

junyor’s picture

junyor commented
Status: Active » Closed (duplicate)

I've made it so the user will get a message to reload the page if the site has password reset disabled and HTTP auth is in use. The rest of this should be discussed in issue #103268.