0004612: #AD_Client_ID versus #User_Client session variables

Description

I cannot see the difference between the above two session variables. I found exactly one occurence for setting either of them and they are both set in the

  fillSessionArguments method of the LoginUtils.java

                // Set session vars
                vars.setSessionValue("#AD_User_ID", strUserAuth);
                vars.setSessionValue("#SalesRep_ID", strUserAuth);
                vars.setSessionValue("#AD_Language", strLanguage);
                vars.setSessionValue("#AD_Role_ID", strRol);
                vars.setSessionValue("#AD_Client_ID", strCliente);
                vars.setSessionValue("#AD_Org_ID", strOrg);
                vars.setSessionValue("#M_Warehouse_ID", strAlmacen);
        ...
                try {
                  SeguridadData[] data = SeguridadData.select(conn, strRol, strUserAuth);
                  if (data==null || data.length==0) return false;
                  vars.setSessionValue("#User_Level", data[0].userlevel);
                  vars.setSessionValue("#User_Client", data[0].clientlist);
        ...

  and the Seguridad_data.xsql specifies this for the select statement
        <SqlClass name="SeguridadData" package="org.openbravo.base.secureApp">
           <SqlClassComment></SqlClassComment>
           <SqlMethod name="select" type="preparedStatement" return="multiple">
              <SqlMethodComment></SqlMethodComment>
              <Sql><![CDATA[
                SELECT r.UserLevel,r.ClientList,r.OrgList,r.C_Currency_ID,r.AmtApproval,
                r.AD_Client_ID, c.NAME, u.C_BPARTNER_ID, c.VALUE, c.SMTPHOST
                FROM AD_ROLE r, AD_CLIENT c, AD_USER u,
                AD_USER_ROLES ur
                WHERE r.AD_Role_ID = to_number(?)
                AND ur.AD_USER_ID = to_number(?)
                AND r.AD_CLIENT_ID = c.AD_CLIENT_ID
                AND r.IsActive='Y' AND c.IsActive='Y'
                AND r.AD_ROLE_ID = ur.AD_ROLE_ID
                AND ur.AD_USER_ID = u.AD_USER_ID
              ]]></Sql>


Basically, as far as i see, the #AD_Client_ID could technically be set to anything if there is a hacked HTTP POST, whereas #User_Client will for sure be set according to the user privileges set inside the database.

However, I can't see any normal circumstance that these two session variables would ever be different, is there? If that is the case, we should then join them into one and make sure the privileges still remain verified through the database, not only use the posted value.

Tags

No tags attached.

Attached Files

Relationships [ Relation Graph ] [ Dependency Graph ]

related to

feature request

0007627

new

Triage Platform Base

Clarify if one role can have access to multiple clients.

Notes
(0013652) shuehner (administrator) 2009-02-18 13:45	I did check the usage of the two mentioned session values: The #User_Client is semantically the list of accessable client for the selected role. The code is prepared to handle several accessable client per role, but currently this seems not be possible to setup in the ui. This value (which is not coming from the request data is used for the security validation of entries. The #AD_Client_ID is taken from the request and is semantically the currently selected client (out of the #User_CLient list). This can be changed into any value by a forged request, however in LoginUtils the value for the selected client is already validated against the clientlist value (#User_Client) so that injection of arbitrary ad_client_id values is prohibited (see function call to ClientComboData.isRoleClient).

(0013657) shuehner (administrator) 2009-02-18 14:13	The possible security issue was checked and the code in question does validate the user input properly. The question if a single role can have access to multiple clients has been spun-off into the featuer request 7627.

Issue History
Date Modified	Username	Field	Change
2008-08-12 17:47	roklenardic	New Issue
2008-08-12 17:47	roklenardic	Assigned To	=> cromero
2008-08-12 17:47	roklenardic	sf_bug_id	0 => 2048144
2008-08-12 17:47	roklenardic	Regression testing	=> No
2008-08-18 10:14	psarobe	Assigned To	cromero => alostale
2008-08-18 10:14	psarobe	Priority	normal => low
2008-08-18 10:14	psarobe	Status	new => scheduled
2008-12-10 09:58	alostale	Assigned To	alostale => iperdomo
2009-01-23 17:16	iperdomo	Assigned To	iperdomo => shuehner
2009-02-18 13:45	shuehner	Note Added: 0013652
2009-02-18 13:45	shuehner	Status	scheduled => feedback
2009-02-18 14:09	shuehner	Relationship added	related to 0007627
2009-02-18 14:13	shuehner	Status	feedback => closed
2009-02-18 14:13	shuehner	Note Added: 0013657
2009-02-18 14:13	shuehner	Resolution	open => no change required