CPG (1.5.26) SMF (2.0.6) - accessing bridgemgr.php while bridged

[gmc]

As I dig into my first attempt at bridging... all seems to be working well - except when I try to access bridgemgr.php while bridged (menu Config -> Bridge Manger in Curve theme)...
I am logged into SMF with an ID in CPG administrator group - and can access all other CPG admin menus - but when I go to bridgemgr - I get the 'Bridge Manager: emergency recovery' screen... which says I need to login - or use the emergency recovery to disable bridging (and top menu bar shows login as option) - but I can go to any other config page successfully - (and on all other pages top menu bar shows already logged in)

Looking at bridgemgr.php, it is apparently failing the test for "if (GALLERY_ADMIN_MODE) {" on line 292...
This should have been set in includes/init.inc.php with "define('GALLERY_ADMIN_MODE', USER_IS_ADMIN && $USER['am']);" on line 257... which is included in bridgemgr.php...

Before I dig deeper - is this incorrect behavior as I suspect?
A normal user account won't show this obviously..
Thanks!

[lurkalot]

As I dig into my first attempt at bridging... all seems to be working well - except when I try to access bridgemgr.php while bridged (menu Config -> Bridge Manger in Curve theme)...
I am logged into SMF with an ID in CPG administrator group - and can access all other CPG admin menus - but when I go to bridgemgr - I get the 'Bridge Manager: emergency recovery' screen... which says I need to login - or use the emergency recovery to disable bridging (and top menu bar shows login as option) - but I can go to any other config page successfully - (and on all other pages top menu bar shows already logged in)


Before I dig deeper - is this incorrect behavior as I suspect?
A normal user account won't show this obviously..
Thanks!

That's how it works for me too. I think it's normal.  I just clicked the bridge manager on one of my test sites, and get this (image attached below) shows the same as you.  If I back page, then I'm still logged in. 

[gmc]

Thanks for the quick reply.

OK... so at least seems I didn't do anything wrong...
But then the only way to view or alter any bridge settings is to use emergency recovery to disable the bridge, and then re-run the wizard?

I would have thought I could go in and at least look at the options set from the CPG side... If changing some of the settings require disabling/re-enabling the bridge - I could see that...

[Αndré]

I haven't checked if this is intended to work as described or if there's an urgent reason.

Have you checked the values of

• USER_IS_ADMIN
• $USER['am']

?

[gmc]

In this case (with an echo added to bridgemgr.php):
USER_IS_ADMIN: 0 - $USER['am']: 1 USER_ID: 0 - USER_NAME: Guest

Chasing the code further - (for my benefit as I'm sure you know this....)
USER_IS_ADMIN is set in udb_base.inc.php in function authenticate...
That is included by (in this case) smf20.inc.php.
Which is included based on $BRIDGE['short_name'] (smf20) - assigned to constant UDB_INTEGRATION - and then included in init.inc.php and call made to authenticate:

Code Select Expand


require_once 'bridge/' . UDB_INTEGRATION . '.inc.php';
...
$cpg_udb->authenticate();

So the 'authenticate' code that sets these variables appears to be included and called.

Not sure why the variables don't get set... ran out of time to dig deeper this morning. Insight from others welcome.

[Αndré]

USER_ID: 0 - USER_NAME: Guest

Of course a guest will never have admin privileges. Hadn't checked the code yet why the user isn't authenticated in that case.

[gmc]

Of course a guest will never have admin privileges. Hadn't checked the code yet why the user isn't authenticated in that case.

Of course... I included user_id and user_name to see if it was just the admin flag not set, or if none of the user attributes were set. Appears none of these variables are being set in this case.
The message was produced while logged in as admin, and navigating to bridgemgr.php.

[Αndré]

I just installed SMF 2.0.7 with default settings and bridged my testbed to it. I can access the bridge manager and change the settings without an issue. Can you please provide some more information about your bridge settings and the group membership of the admin user? Thanks.

[gmc]

SMF is 2.0.6.  Contents of bridge database and $BRIDGE array:

Code Select Expand


Bridge Data:
Array
(
    [short_name] => smf20
    [license_number] =>
    [db_database_name] =>
    [db_hostname] =>
    [db_username] =>
    [db_password] =>
    [full_forum_url] =>
    [relative_path_of_forum_from_webroot] =>
    [relative_path_to_config_file] => ../
    [logout_flag] =>
    [use_post_based_groups] => 1
    [cookie_prefix] =>
    [table_prefix] =>
    [user_table] =>
    [session_table] =>
    [group_table] =>
    [group_relation_table] =>
    [group_mapping_table] =>
    [use_standard_groups] => 1
    [validating_group] =>
    [guest_group] =>
    [member_group] =>
    [admin_group] =>
    [banned_group] =>
    [global_moderators_group] =>
    [recovery_logon_failures] => 0
    [recovery_logon_timestamp] =>
)


The admin user is part of the 'Administrator' group in SMF... SMF groups used in CPG.
All other CPG and SMF admin functions recognize me as admin with this id.


As a test, I disabled the bridge, cleared the bridge table except for the 7 default entries, and re-ran the bridge wizard saying Not to use custom groups...
And with this setting the bridge menu was accessible.... But now I can't use SMF group assignments in Coppermine. .
Contents of bridge database now:

Code Select Expand


Bridge Data:
Array
(
    [short_name] => smf20
    [full_forum_url] =>
    [relative_path_to_config_file] => ../
    [use_post_based_groups] => 0
    [cookie_prefix] =>
    [recovery_logon_failures] => 0
    [recovery_logon_timestamp] =>
)



Lurkalot was having same results, perhaps he can provide his info as well...

Ideally what I think I want is use_standard_groups on... use_post_based_groups off... No way to set that via wizard (at least not that I see), so don't know if that is valid....

I'll do some more testing... But wanted to share what I found so far.

[Αndré]

I initially bridged with use_post_based_groups off and then enabled it later for testing purposes. Seems that it's not the same result as bridging with use_post_based_groups on the first time. Will clear my database and try again with use_post_based_groups on.

[Αndré]

Regardless of the use_post_based_groups setting, my bridge table and $BRIDGE array always just contain the 7 default values:

Code Select Expand

Array
(
    [cookie_prefix] =>
    [full_forum_url] =>
    [recovery_logon_failures] => 0
    [recovery_logon_timestamp] =>
    [relative_path_to_config_file] => ../smf/
    [short_name] => smf20
    [use_post_based_groups] => 1 (respectively 0)
)

Additionally, I haven't found a reference to e.g. use_standard_groups, neither in the Coppermine nor the SMF code. Maybe this is some leftover from earlier bridge versions? But even it is, I don't know how it should affect Coppermine's behavior, if Coppermine doesn't use those values for anything. The only difference I see is that I use a more recent version of SMF than you.

As a test, please delete all those extra rows from your bridge table and see if:
1. the bridge manager recognizes you as admin
2. everything else still works as expected

[gmc]

Haven't forgotten about this... just pulled away on other issues...

I did determine the 'extra' rows appear to be from earlier CPG versions... as all my galleries that go back to the 1.3 days have those rows (even though never bridge) - and a new gallery (installed at 1.5.24 initially) does not.

I will reset the table to just the 7 rows and redo the test - though as you said CPG doesn't reference any of them..

There is a difference in SMF levels... 2.0.6 was latest available when I installed... They just release 2.0.7 in last 2 weeks - with some issues... so I haven't done the upgrade yet. Was letting the 'dust settle' a bit...

lurkalot - is your install 2.06 or 2.07?

More to come when I test...

[lurkalot]

lurkalot - is your install 2.06 or 2.07?

Sorry, meant to come back to this thread after I read it the other day, but as usual forgot.  We've been busy getting TinyPortal 1.1 ready for release.

I'm using SMF 2.0.7  Using the re released patch.  Upgrade only takes a few seconds, and you can roll back to 2.0.6 if it doesn't work out for you.