Closed (fixed)
Project:
Drupal Commons
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
4 Feb 2011 at 15:03 UTC
Updated:
26 Feb 2011 at 20:34 UTC
Jump to comment: Most recent file
The following peace of code in commons.module prevents Invite from working correctly
// Force anonymous users to a login page
if (variable_get('commons_force_login', 0)) {
global $user;
// If anonymous
if (!$user->uid) {
// Avoid endless redirect and allow for user registration/creation/login
// Checking arg(1) for numeric value prevents /user/# path
if (arg(0) != 'user' || is_numeric(arg(1))) {
// Redirect to home
if ($dest = $_GET['q']) {
// If the user was trying to reach a certain page,
// try to preserve the redirection after login
drupal_goto('user', "destination=$dest");
}
else {
drupal_goto('user');
}
}
}
}
It redirects all not logged in users to login page thus preventing invitation code to validate.
The "invite/accept" path should not be redirected.
This can be fixed with following code change
// Force anonymous users to a login page
if (variable_get('commons_force_login', 0)) {
global $user;
// If anonymous
if (!$user->uid) {
// Avoid endless redirect and allow for user registration/creation/login
// Avoid invite/accept from redirect
if ((arg(0) == 'invite') && (arg(1) == 'accept')) return;
// Checking arg(1) for numeric value prevents /user/# path
if (arg(0) != 'user' || is_numeric(arg(1))) {
// Redirect to home
if ($dest = $_GET['q']) {
// If the user was trying to reach a certain page,
// try to preserve the redirection after login
drupal_goto('user', "destination=$dest");
}
else {
drupal_goto('user');
}
}
}
}
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | screenshot_002.png | 18.83 KB | mstef |
Comments
Comment #1
mstef commentedSeems a little strange to invite people to a locked-down site, no?
If anyone can freely register without admin approval, why even force users to login?
Also, if we allow invite requests to bypass the 'lockdown', where do we draw the line? There are a ton of modules that we'd have to account for..
Thoughts?
Comment #2
VSZ commentedWell, here is my thoughts.
I need a site where anonymous users can't see any content and "Force users to login" option is right for me.
Please note that "Force users to login" option does not prevent new users from freely register (with or without admin appoval).
But I need existing users to be able to invite their friends. And Invite module gives me the "New user registration by invitation only." option. And here the commons.module comes and block invite/accept path preventing invitation from validate.
Probably I'm wrong marking this issue as bug report. It shoud be incompatibility (with Invite module) report.
Comment #3
mstef commentedOkay, what I think is best, is to offer a configurable list of allowed URLs. How does that sound?
Comment #4
VSZ commentedSound great for me.
Comment #5
klamzo commentedsubscribing
Comment #6
mstef commentedOkay, I made the necessary changes and have committed. I've attached a screenshot to show what the admin UI looks like now.
If you want to bring in these changes, I suppose you have a few options. You could download the absolutely latest from Github, but I would never recommend doing that for a production site.
I could also create a patch for the relevant file that only contains these minor tweaks. Would you like me to do that? I think that's the best solution here; unless someone has a suggestion.
Comment #7
VSZ commentedSpeaking for myself, the patch would be the best solution.
Many thanks.
Comment #8
mstef commentedWe'll be releasing Commons 1.4 either today or early tomorrow, in response to the security issue in the Messaging module. It will include these changes - so it's probably best just to wait for that.
Comment #9
VSZ commentedI found one more reason for the "Allowed path" option - if "Force users to login" is active cron.php could not be run.
So, waiting for Commons 1.4
Thank you.
Comment #10
mstef commentedNo, that will..
The function that forces the login bails on a few conditions, that being one of them (along with install.php, xmlrpc, if the client is a command line which indicates drush usage usually).
Comment #11
VSZ commentedI use wget to run cron.php and it doesn't work if "Force users to login" enabled.
The only way is manual cron run from admin page.
Comment #12
mstef commentedI have no problem hitting cron.php with wget when the forced login is enabled. 1.4 is now available. Grab that and see if you're still having that problem.
Comment #13
VSZ commentedAllowed path in commons 1.4 works fine.
And no problem with cron.
Many thanks.