Could you please define a Drupal permission check box so that only if the ID has group permission to access UBB does the UBB login cookie get created.
With CiviCRM creating the ID's, we must leave Drupal exposed to people being able to create bogus accounts of their own. Thus currently they end up with UBB permissions automagically. That needs to be stopped ASAP!
We have a Drupal permission group that Civi created ID's ends up a member of, and that is the correct way to exist in our environment.
I guess in the same area of the code, if the mod does not find the check box checked in any of the user's roles, then zap the cookie.
We have the default "authenticated user" role extremely locked down. So if people get "under the covers" and create their own ID, they are worse off than "anonymous"! ;-) So in that case blocking UBB access would be VERY important! Thank you!
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1045298_2.patch | 5.56 KB | muriqui |
| #4 | error.png | 333.78 KB | mdlueck |
| #4 | error-admin.png | 534.62 KB | mdlueck |
| #3 | 1045298.patch | 5.55 KB | muriqui |
Comments
Comment #1
muriqui commentedWill try to take care of this over the weekend. Just keep in mind that this new permission won't prevent the user from logging into UBB, since the account information is still synced, so you'll need to make certain that all direct entry points to UBB are disabled.
Comment #2
mdlueck commentedAny update on this open issue? We would like to get this hole plugged if at all possible. Thank you!
Comment #3
muriqui commentedOK, try this. The patch includes an update hook which automatically sets the permission for authenticated users when you run update.php... This is so that you can update the module without it suddenly breaking functionality for existing users. In your case, you'd want to install the patch, update the module, and then go correct the permissions.
Comment #4
mdlueck commentedA few errors encountered getting the code on the server. The mod seems to have stabilized from its complaints.
First error upon Drupal update.php, second error following disable / uninstall / enable / going to the UBB admin page.
Drupal database update
warning: array_merge() [function.array-merge]: Argument #2 is not an array in /srv/www/sites/christians-in-recovery.org/www/update.php on line 173.
warning: Invalid argument supplied for foreach() in /srv/www/sites/christians-in-recovery.org/www/update.php on line 337.
Updates were attempted. If you see no failures below, you may proceed happily to the administration pages. Otherwise, you may need to update your database manually. All errors have been logged.
Main page
Administration pages
The following queries were executed
ubb module
Update #6100
No queries
<><><><>
After disable / uninstall / enable, going to the UBB admin I received:
user warning: Table 'cir_ubb.VERSION' doesn't exist query: SELECT v.DB_VERSION FROM VERSION v in /srv/www/sites/christians-in-recovery.org/www/sites/all/modules/ubb/ubb.module on line 153.
<><><><><>
We will continue testing with test accounts which do NOT have the UBB perm check box checked and see that they can not access UBB. Since we modified UBB code to redirect to /user if the magic cookie is not acceptable, then I suspect that to be the behavior with your modification.
Oh, and this patch was not included, so I applied this diff to the original mod + 941088
http://drupal.org/files/issues/ubb_issue_941088.patch
Comment #5
muriqui commentedThose messages are harmless, but worth fixing:
As for #941088: UBB session cookie expires immediately not being included, that patch was committed to 6.x-1.x-dev months ago. New patches should always be applied to the latest development release, not the stable release... Just noticed that you filed this issue against beta7, so I've retagged it to dev, which is the correct version tag for feature requests.
Comment #6
mdlueck commentedAhh, all right, I will apply the 1045298_2.patch to the -dev version in the morning and give that scenario a try. I wondered why you said that detail was captured though I could not see it.
I thought I remembered #1289448 from long long ago, so was not alarmed by encountering such.
Thank you very much! So I will send the director an update that I need to change the code on the server before the stress testing begins.
Comment #7
mdlueck commentedI applied 1045298_2.patch to the -dev build, disable / update.php / enable / UBB Drupal perms survived the round trip, reset the TABLE_PREFIX again, couple of reloads of that page got rid of the pink finger, enabled the integration, receive access to UBB.
Contacted the director for them to test member expire situations.
Thank you very much! :-)
Comment #8
mdlueck commentedAccording to the director, -dev + 1045298_2.patch works as needed.
I will flag the status as reviewed in that case.
Thank you so much! :-)
Comment #9
muriqui commentedCommitted to 6.x-1.x-dev.