Hi Gavin:
      Base on the list you mentioned, it indeed needs to identify the
relation between the API caller and the update target, then pop-up the
relation to the UI side. I came up with few solutions for solving the
issue, but there are still some side-effects that trouble me:
        1. The logic you mentioned only happens when an API caller trying to
update the
            password only.
           (What if the API caller wants to modify other attributes with 
password
at the             same time? Ex: command=updateUser&password=xxx&email=xxx)
        2. The logic will be applied to all operations through UpdateUserCmd api
command
           (All the other operations through UpdateUserCmd will use the same
logic as
           updating the password.)

There will be some solutions and side-effects that I didn't expect, please
give more suggestions, thank you.

Best regards

Isaac


On 12/17/12 1:04 PM, "gavin lee (JIRA)" <[email protected]> wrote:

>
>    [
>https://issues.apache.org/jira/browse/CLOUDSTACK-648?page=com.atlassian.ji
>ra.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533650
>#comment-13533650 ]
>
>gavin lee commented on CLOUDSTACK-648:
>--------------------------------------
>
>Hi, Isaac
>You remind me.  I think it makes sense for the domain admin change
>following (we only talk about the password):
>1. Its own password like normal user
>2. The users' password who are in this domain
>3. The subdomain user password
>4. The subdomain admin password
>
>UI should check the user and domain co-relation to decide add entry or
>not.
>Wha't your opinion?
>
>> The normal users could change their own login password
>> ------------------------------------------------------
>>
>>                 Key: CLOUDSTACK-648
>>                 URL:
>>https://issues.apache.org/jira/browse/CLOUDSTACK-648
>>             Project: CloudStack
>>          Issue Type: Bug
>>      Security Level: Public(Anyone can view this level - this is the
>>default.)
>>          Components: Management Server
>>    Affects Versions: 4.1.0
>>         Environment: DevCloud2 and others
>>            Reporter: gavin lee
>>            Priority: Minor
>>              Labels: changes, password, user
>>             Fix For: 4.1.0
>>
>>   Original Estimate: 48h
>>  Remaining Estimate: 48h
>>
>> After created normal users by administrator, using the normal users
>>login should let them change their own password.
>> The easiest way to change this is enable it on the UI by changing
>>scripts/accounts.js and changing access level for api: updateUser in
>>file commands.properties.
>> If there are concerns of security, new api may be introduced.
>> please comment.
>
>--
>This message is automatically generated by JIRA.
>If you think it was sent incorrectly, please contact your JIRA
>administrators
>For more information on JIRA, see: http://www.atlassian.com/software/jira

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>

Reply via email to