Closed (fixed)
Project:
Secure Site
Version:
5.x-1.5
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 Sep 2008 at 14:39 UTC
Updated:
12 May 2014 at 18:26 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
junyor commentedDuplicate of #307339: Securesite prompts continuously unless user has permission, regardless of filter setting.
Comment #2
mkrakowiak commentedJunyor, I don't think it's a duplicate issue. The user was given permissions to access both content and secured pages. Resetting password didn't work, but when the user entered correct password, everything was fine.
Comment #3
junyor commentedI ran into this same issue before applying the fix from the duplicate. Try it to see if it works for you, too.
Comment #4
mkrakowiak commentedWas the fix from the duplicate applied to the dev version? I updated the module with the dev and now when I try recovering a password, I get "Unrecognized username or e-mail address." even though the username or email are correct.
Comment #5
junyor commentedSorry! That's a different bug I fixed tonight. Please try the just-released 5.x-1.5 version.
Comment #6
mkrakowiak commentedAll right, I just updated the module to the very fresh 5.x-1.5 version (I think I was one of the first folks to download it :) ) and the "Unrecognized..." message is gone (fixed), but my previous problem is still there:
When I enter the username OR email address, I receive an email with link to reset it, but clicking on the link takes me to the same Secure Site login page.
Also see the screenshot attached, taken on the Update Status page.
???
Comment #7
junyor commentedI don't know why update status is saying that. Maybe it's cache needs to be updated?
So, you're using the login form and not HTTP Auth, correct? Does the log file say anything about the password URL you used? Is your site installed in a sub-directory or the domain root?
Comment #8
mkrakowiak commentedJunyor, thanks for your time with this. I'm using HTML login form and the site is installed as a... subdomain. Could this cause the problem?
1 more thing: the site is installed in the domain root.
This is what's in the log file:
Type user
Date Wednesday, September 24, 2008 - 22:49
User Visitor
Location http://cpj.mkrakowiak.com/
Referrer http://cpj.mkrakowiak.com/
Message Password mailed to Michael at michael@cpj.ca.
Severity notice
Yeah, I also think (and hope) that with the update status it's the cache thing.
Comment #9
junyor commentedThere shouldn't be a problem if it's installed as a sub-domain. But it's the root of the sub-domain, right? Are you using clean URLs?
Comment #10
mkrakowiak commentedYes, I'm using clean URLs. mkrakowiak.com is the main domain on the account.
I guess, I also should mention that I'm using some other modules that could (?) interfere with Secure Site module. These are: I18n, Password Strength and ACL.
Comment #11
junyor commentedA brief look at the descriptions for those modules doesn't lead me to believe they'd interfere. Are you using custom paths of some sort? Secure Site does some validation of the password reset URL, specifically checking that it contains
$base_path .'user/reset'(see line 237). Maybe add in somewatchdog()statements to see the value of $base_path and request_uri() at that point? Could you send me a sample password reset URL (maybe via my contact form)?Comment #12
mkrakowiak commentedTim, I'm using Pathauto. How would I go about adding watchdog() statements? Right in the SecureSite module?
Comment #13
junyor commentedDon't worry about it, the password reset URL you sent me shows the problem:
http://example.com/en/user/reset/2/...
Because i18n adds "/en" to the URL, the counting done by Secure Site to make sure the password reset URL is valid doesn't work. I'll have to think for a bit how to fix that.
Comment #14
mkrakowiak commentedHmmm... That's what I thought. However, if the link (and counting) is created without the i18n's code - "/en" in this case - it could work. What do you think?
Comment #15
junyor commentedWell, the link is created by Core, so we don't have any control over that. I'll have to see what i18n is doing to change the URLs, I guess.
Comment #16
darren ohTake a look at i18n_selection_mode() in i18n.module. That plus the current language would tell us whether i18n is modifying URLs.
Comment #17
junyor commentedThank you for the pointers, Darren.
Comment #18
junyor commentedWe might be able to solve this independent of i18n. Right now, we're doing three checks:
1) Does the requested URI contain
$base_path .'user/reset/'?2) Does the requested URI contain at least five path elements (domain, "user", "reset", uid, then two unique identifiers, IINM)?
3) Is the UID referenced in the URI blocked?
The URI is failing because of the first check. We could improve the check by using
drupal_get_path_alias()to check for aliases, but that still wouldn't help in this case because there's something between the domain and the path/alias. What if we check just the path portion for "user/reset/" and a valid UID instead of trying to match the full URL? Or, we could allow a wild card between the domain and path/alias.Darren: Any thoughts?
Comment #19
NaX commentedIf you are going to do partial url matching we need to be careful of "Access bypass Vulnerability". Securesite has already experienced a problem with this type of vulnerability when it comes to the cron bypass.
Comment #20
darren ohComment #21
darren ohFixed for HEAD in CVS commit 149843. Please test the attached patch for the Drupal 5 version.
Comment #22
mkrakowiak commentedJust confirming that the patch works. Thanks for your help, Darren, Junyor and NaX.
Comment #23
darren ohFixed in CVS commit 151984.