David,
I really did not describe it very well, sorry.
I don't think there is a problem with the createUserLogin service
definition or implementation.
The issue (maybe) could be the way the framework handles the minilang
attribute include-user-login="true": it just gets the "userLogin" object
from the context of the calling service and put it in the context of the
called service, even if in the context of the called service there is
already a "userLogin" object.
So for example the code in the createPersonAndUserLogin service (for
which I have provided the patch) is:
<!-- call the service with the system account to get around security
constraints for this special create -->
<entity-one entity-name="UserLogin" value-name="createUlInMap.userLogin">
<field-map field-name="userLoginId" value="system"/>
</entity-one>
<call-service service-name="createUserLogin" in-map-name="createUlInMap"
include-user-login="false"/>
Unfotunately the "system" userLogin object that is manually put in the
input context for the createUserLogin service is overriden (by the
framework), if one is available in the context of the
createPersonAndUserLogin service because the include-user-login
attribute defaults to true.
Just adding the include-user-login="false" attribute to the service call
fixed the issue.
Does it make sense?
Jacopo
David E. Jones wrote:
On Jan 25, 2007, at 7:41 AM, Jacopo Cappellato wrote:
Hi all,
could you have a look at the attached simple patch? It fixes an
authorization problem under some special situations (switching from
anonymous user to authenticated one...); however the issue is that,
when the "createUserLogin" is called, if the attribute
include-user-login is not set to false the manually passed in "system"
user is overwritten by the user in the context.
I just traced through the code to try to figure out why this might be
happening, and either I don't understand what you're describing, or I
just can't find why this would happen.
In the implementation of the service
(LoginServices.java:createUserLogin) I don't see anything that would do
this. In the service definition I don't see it either because the
service definition does not have a "userLogin" parameter going out.
Have you traced down the code that would be putting the user in the
context? Also, do you mean by this the context of the current service
call (ie for other services called by ECA rules, etc), or in the result
(returned) Map of the service, or somewhere else?
I apologize for pushing on the detail, I may just be too brain-dead to
see it right now.
-David
Should I commit this patch?
Or, in general, would be better, even if include-user-login is true,
to set the user login only if one is not already there in the service
in map?
Jacopo
Index:
applications/party/script/org/ofbiz/party/party/PartySimpleMethods.xml
===================================================================
---
applications/party/script/org/ofbiz/party/party/PartySimpleMethods.xml
(revisione 499802)
+++
applications/party/script/org/ofbiz/party/party/PartySimpleMethods.xml
(copia locale)
@@ -85,7 +85,7 @@
<field-map field-name="userLoginId" value="system"/>
</entity-one>
- <call-service service-name="createUserLogin"
in-map-name="createUlInMap"/>
+ <call-service service-name="createUserLogin"
in-map-name="createUlInMap" include-user-login="false"/>
<entity-one entity-name="UserLogin" value-name="newUserLogin"/>
<field-to-result field-name="newUserLogin"/>
