0004612: #AD_Client_ID versus #User_Client session variables

Openbravo Issue Tracking System - Openbravo ERP

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0004612

Openbravo ERP

A. Platform

public

2008-08-12 17:47

2009-02-18 14:13

Reporter

roklenardic

Assigned To

shuehner

Priority

low

Severity

minor

Reproducibility

always

Status

closed

Resolution

no change required

Platform

OS Version

Ubuntu 8.04

Product Version

2.40alpha-r3

Target Version

Fixed in Version

Merge Request Status

Review Assigned To

OBNetwork customer

Web browser

Modules

Core

Support ticket

Regression level

Regression date

Regression introduced in release

Regression introduced by commit

Triggers an Emergency Pack

Summary

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.

Steps To Reproduce

Proposed Solution

Additional Information