Re: Changes to the Security & Permissions concept?

[c.schinzer-2]

Further to this, I do see this error message on the logs for almost every
screen I open on the backend apps:

Service auth failed for userLoginId [admin] because UserLogin record
currentPassword fields did not match; note that the UserLogin object passed
into a service may need to have the currentPassword encrypted

Maybe that give a hint of what I am facing.
Any comments?

2012/8/22 Carsten Schinzer <[hidden email]>

> Hello all,
>
>
> I recently migrated from 09.04 to trunk with my OFBiz basic setup.
>
> Since that point I seem to have issues when working in roles such as
> admin, ltdadmin for example:
> * I cannot view recent CustReqeusts as admin or ltdadmin
> * I have no rights to change shop settings as admin or ltdadmn
> etc.
>
> Does anyone have guidance on
> * when did things change ? (JIRA reference possibly?)
> * is there an associated, recommended migration path for existing setups?
> * which data reader levels do I need to repeat (seed-initial, seed) to
> establish full default permission set for admin & co?
>
> Any guidance will be much appreciated.
>
> Thanks & regards
>
>
> Carsten
>
>

[c.schinzer-2]

Guys, I am still running with this (I can only do that part-time in my
evenings). Here is more findings (but still no solution):

The error message is legged when in methodContext there is no userId set.
Now I wonder how that can happen, as I am logging into the ordermgr
application (with permissions set to ORDERMGR_ADMIN), then define a search
on the CustRequest search form before I get the error message in the logs
when the result list is rendered.

Also strange: When I try to change my password I get thrown out from the
PartyMgr screen as having no permission.

Even more strange: When I attempt to see PartyMgr function from the menu I
am prompted to change my password.

Finally entirely strange: Checking the encrypted default passwords from the
demo data files I see a discrepancy between trunk demo data and 10.04 demo
data. Assuming, both string values represent a SHA-hashed "ofbiz" as a
password, then why are they different as follows:

10.04 hashed value: currentPassword=
"{SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a"
trunk hashed value: currentPassword=
"{SHA}47b56994cbc2b6d10aa1be30f70165adb305a41a"

I admit I am confused. If anyone can shed light into this .... very much
appreciated.

Did I miss a step when upgrading from 10.04 to trunk recently ?

Thanks & regards


Carsten

[Jacques Le Roux]

Adam (doogie) has introduced some changes recently (early may) in this area, could be related...

Jacques

From: "Carsten Schinzer" <[hidden email]>

> Guys, I am still running with this (I can only do that part-time in my
> evenings). Here is more findings (but still no solution):
>
> The error message is legged when in methodContext there is no userId set.
> Now I wonder how that can happen, as I am logging into the ordermgr
> application (with permissions set to ORDERMGR_ADMIN), then define a search
> on the CustRequest search form before I get the error message in the logs
> when the result list is rendered.
>
> Also strange: When I try to change my password I get thrown out from the
> PartyMgr screen as having no permission.
>
> Even more strange: When I attempt to see PartyMgr function from the menu I
> am prompted to change my password.
>
> Finally entirely strange: Checking the encrypted default passwords from the
> demo data files I see a discrepancy between trunk demo data and 10.04 demo
> data. Assuming, both string values represent a SHA-hashed "ofbiz" as a
> password, then why are they different as follows:
>
> 10.04 hashed value: currentPassword=
> "{SHA}47ca69ebb4bdc9ae0adec130880165d2cc05db1a"
> trunk hashed value: currentPassword=
> "{SHA}47b56994cbc2b6d10aa1be30f70165adb305a41a"
>
> I admit I am confused. If anyone can shed light into this .... very much
> appreciated.
>
> Did I miss a step when upgrading from 10.04 to trunk recently ?
>
> Thanks & regards
>
>
> Carsten
>

[c.schinzer-2]

After adding a little Debug output on the Service Dispatcher it is clear
what's going on:

ServiceDispatcher.getDelegator() returns the default delegator while my
userLogin in context is valid for a tenant delegator, ie. default#MYTENANT

Is this a known issue? Has anyone attempted to adapt the ServiceDispatcher
to use the current user's context delegator? Is there risk bound to it? Or
should I just locally adapt the auth method to use the correct delegator
and keep ServiceDispatcher.delegator with the 'default' ?

I shall go for that latter and play around a bit while waiting for replies
here.

Once solution found, it merit's a JIRA I guess.

Regards


Carsten

2012/8/23 Jacques Le Roux <[hidden email]>

> Adam (doogie) has introduced some changes recently (early may) in this
> area, could be related...
>
> Jacques
>
> From: "Carsten Schinzer" <[hidden email]>
>
>  Guys, I am still running with this (I can only do that part-time in my
>> evenings). Here is more findings (but still no solution):
>>
>> The error message is legged when in methodContext there is no userId set.
>> Now I wonder how that can happen, as I am logging into the ordermgr
>> application (with permissions set to ORDERMGR_ADMIN), then define a search
>> on the CustRequest search form before I get the error message in the logs
>> when the result list is rendered.
>>
>> Also strange: When I try to change my password I get thrown out from the
>> PartyMgr screen as having no permission.
>>
>> Even more strange: When I attempt to see PartyMgr function from the menu I
>> am prompted to change my password.
>>
>> Finally entirely strange: Checking the encrypted default passwords from
>> the
>> demo data files I see a discrepancy between trunk demo data and 10.04 demo
>> data. Assuming, both string values represent a SHA-hashed "ofbiz" as a
>> password, then why are they different as follows:
>>
>> 10.04 hashed value: currentPassword=
>> "{SHA}**47ca69ebb4bdc9ae0adec130880165**d2cc05db1a"
>> trunk hashed value: currentPassword=
>> "{SHA}**47b56994cbc2b6d10aa1be30f70165**adb305a41a"
>>
>> I admit I am confused. If anyone can shed light into this .... very much
>> appreciated.
>>
>> Did I miss a step when upgrading from 10.04 to trunk recently ?
>>
>> Thanks & regards
>>
>>
>> Carsten
>>
>>

[c.schinzer-2]

And a last one that may be commented by other users of multitenancy,
possibly:

Because of the fact that the ServiceDispatcher uses the default delegator,
I also cannot see my tenant's data. E.g. I do not see the tenant's orders,
customer requests etc.

I tried to find out why the delegator (which is set properly in the
ContextFilter), does not make it into the Service call, but no success. The
Service call for this one is defined in the CustRequestForms.xml and simply
maps the Form parameters to the service call. I am not sure how to access
request parameters to enrich the service call with e.g. the tenantId.

I can see this works fine in other places since the JobInvoker is able to
call services with the correct delegator. I am just not sure about the
processing chain for backend application calls. Any hint anyone?

Thanks & regards


Carsten

2012/8/24 Carsten Schinzer <[hidden email]>

> After adding a little Debug output on the Service Dispatcher it is clear
> what's going on:
>
> ServiceDispatcher.getDelegator() returns the default delegator while my
> userLogin in context is valid for a tenant delegator, ie. default#MYTENANT
>
> Is this a known issue? Has anyone attempted to adapt the ServiceDispatcher
> to use the current user's context delegator? Is there risk bound to it? Or
> should I just locally adapt the auth method to use the correct delegator
> and keep ServiceDispatcher.delegator with the 'default' ?
>
> I shall go for that latter and play around a bit while waiting for replies
> here.
>
> Once solution found, it merit's a JIRA I guess.
>
> Regards
>
>
> Carsten
>
>
> 2012/8/23 Jacques Le Roux <[hidden email]>
>
>> Adam (doogie) has introduced some changes recently (early may) in this
>> area, could be related...
>>
>> Jacques
>>
>> From: "Carsten Schinzer" <[hidden email]>
>>
>>  Guys, I am still running with this (I can only do that part-time in my
>>> evenings). Here is more findings (but still no solution):
>>>
>>> The error message is legged when in methodContext there is no userId set.
>>> Now I wonder how that can happen, as I am logging into the ordermgr
>>> application (with permissions set to ORDERMGR_ADMIN), then define a
>>> search
>>> on the CustRequest search form before I get the error message in the logs
>>> when the result list is rendered.
>>>
>>> Also strange: When I try to change my password I get thrown out from the
>>> PartyMgr screen as having no permission.
>>>
>>> Even more strange: When I attempt to see PartyMgr function from the menu
>>> I
>>> am prompted to change my password.
>>>
>>> Finally entirely strange: Checking the encrypted default passwords from
>>> the
>>> demo data files I see a discrepancy between trunk demo data and 10.04
>>> demo
>>> data. Assuming, both string values represent a SHA-hashed "ofbiz" as a
>>> password, then why are they different as follows:
>>>
>>> 10.04 hashed value: currentPassword=
>>> "{SHA}**47ca69ebb4bdc9ae0adec130880165**d2cc05db1a"
>>> trunk hashed value: currentPassword=
>>> "{SHA}**47b56994cbc2b6d10aa1be30f70165**adb305a41a"
>>>
>>> I admit I am confused. If anyone can shed light into this .... very much
>>> appreciated.
>>>
>>> Did I miss a step when upgrading from 10.04 to trunk recently ?
>>>
>>> Thanks & regards
>>>
>>>
>>> Carsten
>>>
>>>
>