View Issue Details

IDProjectCategoryView StatusLast Update
0011738mantisbtauthenticationpublic2014-12-08 00:34
ReporterbobonovAssigned Todhx 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.0 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0011738: $g_session_key parameter is not working
Description
In config_defaults_inc.php there is the following parameter:

/**

  • Session key name. Should be unique between multiple installations to prevent conflicts.
  • @global string $g_session_key
    */
    $g_session_key = 'MantisBT';

Trying to use it and is not working, different installation with different $g_session_key value share the session.

Steps To Reproduce

I made a first installation, configured it and inserted all the users.
Then I made a different installation on the same webserver but different folder.
I made it pointing to a different db and imported all the data of the other installation.
I need this one to test mantis configuration before making them on the production one.
I changed $g_session_key = 'MantisBT'; to $g_session_key = 'MantisBTtestingEnviroment';
When I log in the first one I get automatically logged on the second one.
If I log out from one both get logged out.
If I log in on the first one with a user and after with a different user on the second one, the first one switch to the user used on the second one.

Additional Information

This can lead to potential security issue if a user have different privileges on the two installations.

TagsNo tags attached.

Relationships

related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 

Activities

dhx

dhx

2010-04-01 04:21

reporter   ~0024995

I assume you've set $g_cookie_path to a different value for each installation?

bobonov

bobonov

2010-04-08 06:42

reporter   ~0025069

I thought that everything about multiple installation was managed by a single option.
Now I looked to the cookies options.
It was sufficient to modify $g_cookie_prefix parameter.

May be it is useful in the configuration file to add to the comments of $g_session_key that you must modify also $g_cookie_prefix.
Another possibility is to have the configuration get the $g_session_key value as $g_cookie_prefix defaults.
Something like:

    /**
     * --- cookie prefix ---------------
     * set this to a unique identifier.  No spaces.
     * @global string $g_cookie_prefix
     */
    $g_cookie_prefix                = $g_session_key;

So if the user change $g_session_key everything is working as expected, and the user still have the possibility to do more personalisation.

dhx

dhx

2010-09-19 02:08

reporter   ~0026774

I don't see any need to allow MantisBT administrators to set the session key themselves. We should be able to just assign a random value to it based on the new $g_crypto_random_salt configuration option in MantisBT 1.3.x.

dhx

dhx

2010-12-25 04:27

reporter   ~0027700

Removed $g_session_key - it is now derived from $g_crypto_master_salt.

grangeway

grangeway

2013-04-05 17:57

reporter   ~0036239

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

Related Changesets

MantisBT: master 1416aaf1

2010-12-25 09:20:45

dhx

Details Diff
Issue 0011738: Deprecate $g_session_key configuration option

We don't need to use a unique 'session_key' configuration option anymore
as we can just derive a unique key from $g_crypto_master_salt.
mod - config_defaults_inc.php Diff File
mod - core/obsolete.php Diff File
mod - core/session_api.php Diff File

MantisBT: master e487d70f

2010-12-25 13:07:10

dhx

Details Diff
Fix 0011738: Use an ASCII compatible session key

Commit 1416aaf1343a7d2122a099a5e6feb1f847621f2d deprecated
$g_session_key in favour of a unique key automatically derived from
$g_crypto_master_salt. However a bug existed in this commit whereby the
output of the hash() function was raw data, thus leading to failure of
PHP sessions. We need to ensure that the session key is ASCII
compatible.
mod - core/session_api.php Diff File

Issue History

Date Modified Username Field Change
2010-04-01 04:11 bobonov New Issue
2010-04-01 04:21 dhx Note Added: 0024995
2010-04-08 06:42 bobonov Note Added: 0025069
2010-09-19 02:08 dhx Note Added: 0026774
2010-09-19 02:08 dhx Assigned To => dhx
2010-09-19 02:08 dhx Status new => acknowledged
2010-09-19 02:08 dhx Target Version => 1.3.0-beta.1
2010-12-25 04:26 dhx Changeset attached => MantisBT master 1416aaf1
2010-12-25 04:27 dhx Note Added: 0027700
2010-12-25 04:27 dhx Status acknowledged => resolved
2010-12-25 04:27 dhx Fixed in Version => 1.3.0-beta.1
2010-12-25 04:27 dhx Resolution open => fixed
2010-12-25 08:17 dhx Changeset attached => MantisBT master e487d70f
2013-04-05 17:57 grangeway Status resolved => acknowledged
2013-04-05 17:57 grangeway Note Added: 0036239
2013-04-05 18:42 grangeway Relationship added related to 0015721
2013-04-06 03:44 dregad Status acknowledged => resolved
2013-04-06 07:20 grangeway Status resolved => acknowledged
2013-04-06 09:26 dregad Tag Attached: 2.0.x check
2013-04-06 09:26 dregad Status acknowledged => resolved
2014-09-23 18:05 grangeway Tag Detached: 2.0.x check
2014-12-08 00:34 vboctor Status resolved => closed