View Issue Details

IDProjectCategoryView StatusLast Update
0008381mantisbtadministrationpublic2016-07-11 15:34
Reporterjoshb Assigned To 
Status confirmedResolutionopen 
Product Version1.1.0a4 
Summary0008381: Setting Configuration Option Fails

Setting the configuration option for default_home_page for a specific member produces the entered result for all users despite the configuration setting entered.

Steps To Reproduce

Set specific member ie: guest/anonymous
Set Project Name: All Projects
Set Configuration Option: default_home_page
Set Type: string
Set Value: main_page.php

Additional Information

Have only tried this with default_home_page but I suspect this may be the case with any setting entered.

TagsNo tags attached.




2007-09-21 11:22

reporter   ~0015681

That's not exactly the bug. The bug is that in the login.php file the config_get functions are located before the authentication so the default home page is not the one configured for a specific user.

In the login.php file the line "$f_return = gpc_get_string( 'return', config_get( 'default_home_page' ) );" must be removed and added into the following if structure:
if ( auth_attempt_login( $f_username, $f_password, $f_perm_login ) ) {
$f_return = gpc_get_string( 'return', config_get( 'default_home_page' ) );
$t_redirect_url = 'login_cookie_test.php?return=' . urlencode( $f_return );
} else {
$f_return = gpc_get_string( 'return', config_get( 'default_home_page' ) );
$t_redirect_url = 'login_page.php?return=' . urlencode( $f_return ) . '&error=1';

    if ( HTTP_AUTH == config_get( 'login_method' ) ) {




2007-09-21 11:44

reporter   ~0015682

Does this show the same behavior when returning to the Mantis site with the permanent login cookie? ie, if the Mantis login url is - log yourself in, then visit and see where it takes you. Does that obey the per-user configuration as it should, or does it still have problems?



2007-09-21 11:46

reporter   ~0015683

Patch applied but this still does not solve the issue.

The issue lies in part that the login_page.php applies a return string to the url based on the current logged in settings, which would be guest/anonymous. That return string is overriding any configuration changes being applied by the db.

I'm not sure there is a way to solve this because of the way it's set ie: anonymous users being logged into the system. I don't understand why viewers would need to be logged in at all. If the project is set to public why would you need to be logged in to view it? That simply doesn't make any sense.

Much like a forum system or any other web membership website for that matter - unless you wish to participate there's no need to be logged in. I'm not sure why it was set up this way but since it is - there may not be a way to get this done without killing the current anonymous session that exists, then forwarding them to the login_page so that no return url is created.



2007-09-21 12:08

reporter   ~0015684


Yes - after exiting the site completely when logged in - then returning to the url the per-user config works as expected. It's only on login that it fails to operate properly.



2007-09-24 02:53

reporter   ~0015699

Ok, so there is no solution.



2007-09-24 03:07

reporter   ~0015700

Well that's an excellent answer. Why didn't I think of that?