-
Notifications
You must be signed in to change notification settings - Fork 899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linking Tower's username and VMDB Authentication.userid for UI edit rendering #14900
Comments
I can think of the following ways solving this,
So, someone has to come up with other ways |
the BZ tracking this is actually https://bugzilla.redhat.com/show_bug.cgi?id=1446033 |
So, can we go with the first option?
EDIT Sorry, this isn't a real suggestion. But, I'm completely lost as to what the underlying problem actually is here. |
I dont get this :( Are we returning the data via the rest api or not? From what I've read, we do, but at a different place. Reading #14902 (comment) seems we should make GET, POST and OPTIONS consistent. @jntullo can you comment on @mzazrivec statement? |
The information is being returned via the API, but in a different place than is being specified when you make a call to On the last option, instead of storing the |
@jntullo can you point to some code that shows where this is breaking down? I'm completely lost in trying to understand the difference between |
why cant it be in the same place? could you show the API json examples? |
@blomquisg this is breaking down because the model is telling the user that this information should be stored in |
@jntullo ok, I think I got username vs userid: this would work if settle on the correct field (which is userid) But what about password and security_token. The UI cant display them. Are you returning them via the REST API? |
So, ignore the view screenshots, they are not using the rest api |
{
"href":"https://10.8.198.79/api/authentications/9",
"id":9,
"name":"awssadf",
"userid":"asdasd",
"resource_id":1,
"resource_type":"ExtManagementSystem",
"created_on":"2017-04-27T19:56:21Z",
"updated_on":"2017-04-27T21:22:38Z",
"type":"ManageIQ::Providers::EmbeddedAnsible::AutomationManager::AmazonCredential",
"htpassd_users":[
],
"ldap_id":[
],
"ldap_email":[
],
"ldap_name":[
],
"ldap_preferred_user_name":[
],
"request_header_headers":[
],
"request_header_preferred_username_headers":[
],
"request_header_name_headers":[
],
"request_header_email_headers":[
],
"open_id_extra_scopes":[
],
"github_organizations":[
],
"manager_ref":"4",
"options":{
"security_token":"$encrypted$"
},
"actions":[
{
"name":"delete",
"method":"post",
"href":"https://10.8.198.79/api/authentications/9"
},
{
"name":"edit",
"method":"post",
"href":"https://10.8.198.79/api/authentications/9"
},
{
"name":"delete",
"method":"delete",
"href":"https://10.8.198.79/api/authentications/9"
}
]
} |
{
"attributes":[
"authtype",
"certificate_authority",
"challenge",
"created_on",
"credentials_changed_on",
"fingerprint",
"github_organizations",
"google_hosted_domain",
"htpassd_users",
"id",
"last_invalid_on",
"last_valid_on",
"ldap_bind_dn",
"ldap_email",
"ldap_id",
"ldap_insecure",
"ldap_name",
"ldap_preferred_user_name",
"ldap_url",
"login",
"manager_ref",
"name",
"open_id_authorization_endpoint",
"open_id_extra_authorize_parameters",
"open_id_extra_scopes",
"open_id_sub_claim",
"open_id_token_endpoint",
"open_id_user_info",
"options",
"public_key",
"request_header_challenge_url",
"request_header_email_headers",
"request_header_headers",
"request_header_login_url",
"request_header_name_headers",
"request_header_preferred_username_headers",
"resource_id",
"resource_type",
"rhsm_pool_id",
"rhsm_server",
"rhsm_sku",
"status",
"status_details",
"type",
"updated_on",
"userid"
],
"virtual_attributes":[
"href_slug",
"region_description",
"region_number"
],
"relationships":[
"authentication_configuration_script_bases",
"authentication_orchestration_stacks",
"configuration_script_bases",
"configuration_script_sources",
"orchestration_stacks",
"resource"
],
"subcollections":[
],
"data":{
"credential_types":{
"external_credential_types":{
"ManageIQ::Providers::AnsibleTower::AutomationManager::MachineCredential":{
"label":"Machine",
"type":"machine",
"attributes":{
"userid":{
"label":"Username",
"help_text":"Username for this credential"
},
"password":{
"type":"password",
"label":"Password",
"help_text":"Password for this credential"
},
"ssh_key_data":{
"type":"password",
"multiline":true,
"label":"Private key",
"help_text":"RSA or DSA private key to be used instead of password"
},
"ssh_key_unlock":{
"type":"password",
"label":"Private key passphrase",
"help_text":"Passphrase to unlock SSH private key if encrypted",
"max_length":1024
},
"become_method":{
"type":"choice",
"label":"Privilege Escalation",
"help_text":"Privilege escalation method",
"choices":[
"",
"sudo",
"su",
"pbrun",
"pfexec"
]
},
"become_username":{
"type":"string",
"label":"Privilege Escalation Username",
"help_text":"Privilege escalation username",
"max_length":1024
},
"become_password":{
"type":"password",
"label":"Privilege Escalation Password",
"help_text":"Password for privilege escalation method",
"max_length":1024
},
"vault_password":{
"type":"password",
"label":"Vault password",
"help_text":"Vault password",
"max_length":1024
}
}
},
"ManageIQ::Providers::AnsibleTower::AutomationManager::ScmCredential":{
"label":"Scm",
"type":"scm",
"attributes":{
"userid":{
"label":"Access Key",
"help_text":"AWS Access Key for this credential"
},
"password":{
"type":"password",
"label":"Secret Key",
"help_text":"AWS Secret Key for this credential"
},
"ssh_key_unlock":{
"type":"password",
"label":"Private key passphrase",
"help_text":"Passphrase to unlock SSH private key if encrypted",
"max_length":1024
},
"ssh_key_data":{
"type":"password",
"label":"Private key",
"help_text":"RSA or DSA private key to be used instead of password"
}
}
},
"ManageIQ::Providers::AnsibleTower::AutomationManager::AmazonCredential":{
"type":"cloud",
"label":"Amazon",
"attributes":{
"userid":{
"label":"Access Key",
"help_text":"AWS Access Key for this credential",
"required":true
},
"password":{
"type":"password",
"label":"Secret Key",
"help_text":"AWS Secret Key for this credential",
"required":true
},
"security_token":{
"type":"password",
"label":"STS Token",
"help_text":"Security Token Service(STS) Token for this credential",
"max_length":1024
}
}
},
"ManageIQ::Providers::AnsibleTower::AutomationManager::VmwareCredential":{
"label":"VMware",
"type":"cloud",
"attributes":{
"userid":{
"label":"Username",
"help_text":"Username for this credential",
"required":true
},
"password":{
"type":"password",
"label":"Password",
"help_text":"Password for this credential",
"required":true
},
"host":{
"type":"string",
"label":"vCenter Host",
"help_text":"The hostname or IP address of the vCenter Host",
"max_length":1024,
"required":true
}
}
}
},
"embedded_ansible_credential_types":{
"ManageIQ::Providers::EmbeddedAnsible::AutomationManager::MachineCredential":{
"label":"Machine",
"type":"machine",
"attributes":{
"userid":{
"label":"Username",
"help_text":"Username for this credential"
},
"password":{
"type":"password",
"label":"Password",
"help_text":"Password for this credential"
},
"ssh_key_data":{
"type":"password",
"multiline":true,
"label":"Private key",
"help_text":"RSA or DSA private key to be used instead of password"
},
"ssh_key_unlock":{
"type":"password",
"label":"Private key passphrase",
"help_text":"Passphrase to unlock SSH private key if encrypted",
"max_length":1024
},
"become_method":{
"type":"choice",
"label":"Privilege Escalation",
"help_text":"Privilege escalation method",
"choices":[
"",
"sudo",
"su",
"pbrun",
"pfexec"
]
},
"become_username":{
"type":"string",
"label":"Privilege Escalation Username",
"help_text":"Privilege escalation username",
"max_length":1024
},
"become_password":{
"type":"password",
"label":"Privilege Escalation Password",
"help_text":"Password for privilege escalation method",
"max_length":1024
},
"vault_password":{
"type":"password",
"label":"Vault password",
"help_text":"Vault password",
"max_length":1024
}
}
},
"ManageIQ::Providers::EmbeddedAnsible::AutomationManager::ScmCredential":{
"label":"Scm",
"type":"scm",
"attributes":{
"userid":{
"label":"Access Key",
"help_text":"AWS Access Key for this credential"
},
"password":{
"type":"password",
"label":"Secret Key",
"help_text":"AWS Secret Key for this credential"
},
"ssh_key_unlock":{
"type":"password",
"label":"Private key passphrase",
"help_text":"Passphrase to unlock SSH private key if encrypted",
"max_length":1024
},
"ssh_key_data":{
"type":"password",
"label":"Private key",
"help_text":"RSA or DSA private key to be used instead of password"
}
}
},
"ManageIQ::Providers::EmbeddedAnsible::AutomationManager::AmazonCredential":{
"type":"cloud",
"label":"Amazon",
"attributes":{
"userid":{
"label":"Access Key",
"help_text":"AWS Access Key for this credential",
"required":true
},
"password":{
"type":"password",
"label":"Secret Key",
"help_text":"AWS Secret Key for this credential",
"required":true
},
"security_token":{
"type":"password",
"label":"STS Token",
"help_text":"Security Token Service(STS) Token for this credential",
"max_length":1024
}
}
},
"ManageIQ::Providers::EmbeddedAnsible::AutomationManager::VmwareCredential":{
"label":"VMware",
"type":"cloud",
"attributes":{
"userid":{
"label":"Username",
"help_text":"Username for this credential",
"required":true
},
"password":{
"type":"password",
"label":"Password",
"help_text":"Password for this credential",
"required":true
},
"host":{
"type":"string",
"label":"vCenter Host",
"help_text":"The hostname or IP address of the vCenter Host",
"max_length":1024,
"required":true
}
}
}
}
}
}
} |
I'm not sure why the field can't just be called userid from the OPTIONS. Then we know that's a column and just write it into the column. I guess I don't understand why username needs to even be a thing. Same goes for password or any other column. |
@mzazrivec @AparnaKarve I believe the issue here is the UI can't be sure from which field in the API request to get the value. Since userid, and password and perhaps others, are straight attributes, they will appear in the base during an API call. However, the rest appear under "options" heading in the API call. Chopping down what @durandom wrote... Here is an OPTIONS call where userid and another field appear the same... "data":{
"credential_types":{
"external_credential_types":{
"ManageIQ::Providers::AnsibleTower::AutomationManager::MachineCredential":{
"label":"Machine",
"type":"machine",
"attributes":{
"userid":{
"label":"Username",
"help_text":"Username for this credential"
},
...
"become_username":{
"type":"string",
"label":"Privilege Escalation Username",
"help_text":"Privilege escalation username",
"max_length":1024
},
... However, when reading from the API, they appear like the following, so they are at different nestings, and thus the UI has no idea where to look. {
"href":"https://10.8.198.79/api/authentications/9",
"id":9,
"name":"awssadf",
"userid":"asdasd",
...
"options":{
"become_username":"sdfjksdfj"
},
...
} Thus I recommend number 2, but would like to know why the idea was shot down. We can of course debate the name "native_attr", or whether we conversely mark only the ones that live under options. I am trying to come at this from an API perspective and not a pure UI perspective, so I am also trying to understand how regular API users might be confused by this. As such, @abellotti, how would this work from the manageiq-api-client standpoint? |
Alternately, perhaps we should change the OPTIONS call to mirror the GET call by having a nested "options" key somewhere. That is, something like "data":{
"credential_types":{
"external_credential_types":{
"ManageIQ::Providers::AnsibleTower::AutomationManager::MachineCredential":{
"label":"Machine",
"type":"machine",
"attributes":{
"userid":{
"label":"Username",
"help_text":"Username for this credential"
},
...
"options": {
"become_username":{
"type":"string",
"label":"Privilege Escalation Username",
"help_text":"Privilege escalation username",
"max_length":1024
},
...
},
... @bdunne @jntullo @abellotti Thoughts? |
@Fryguy I believe the reasoning behind not choosing #2 is because then the way you create an authentication is different from the way you get an authentication and all of its attributes. I agree that it's probably not the best way to go because of that, as it's not intuitive from a user's perspective. In other API collections such as with that said, I like your idea of having OPTIONS call mirror the GET call 😄 |
👍 on the OPTIONS reflecting what GET call returns, would work with options, or any other nested/hash attributes. |
@Fryguy Yes, the OPTIONS call mirroring the GET would be great! That said, I will wait for the new OPTIONS PR and hold off from making any changes in the UI (with regard to BTW, how do we plan to send |
password will never come back from the database, and I would even never send an encrypted string back to the caller. Just assume you won't have a value. I would also never send back security_token...that seems like a potential security issue IMO. |
Ok, so for the password fields, the new and improved OPTIONS call should only send the attribute names like The only time the UI would be really dealing with a password would be when -- |
So here is how ansible tower handles this:
This way you can at least show **** for a set pw and '' for nothing @jntullo do we do something similar in our API to retain a pw? Or do we implement PATCH requests to do partial updates? |
@durandom The API does partial updates. A lot of the specifics depend on the model itself - there's not much logic in the actual controller |
In this case, model/backend doesn't really look into what is being passed to Tower (except translating |
@jameswnl What about the PUT call? |
@AparnaKarve my understanding is: TowerClient Gem is always using |
@durandom Oh you mean it sends LITERALLY |
Yes, it's literally In any case, the UI should not be sending any password fields if it's not creating a record or not updating a password field. |
FYI,
|
are you using the patch directives as mentioned in http://manageiq.org/docs/reference/latest/api/overview/http#updating-resources in the payload, or just the attributes ? in the latter case you probably just want a PUT or POST with "edit" action. |
I was using just the attributes, so that could be the reason. @abellotti @jntullo Any idea if PUT supports a partial update? EDIT: Just to be very clear, I'm OK using PUT/PATCH as long as either call supports a partial update. |
PUT supports partial, essentially similar to a POST edit. |
@durandom FYI: While the Notification in the UI displays the password as
|
@AparnaKarve nice find. Could you try to add |
@AparnaKarve yes, it would. |
@jameswnl Is this issue still open? |
no, closing it .... |
Hello I am looking for to get the AWS credentials by calling Authentication API of manageIQ. Bur only able to see access key .. please help to get the secret key. Appreciate your help :) Here is the sample data i am getting once i called /api/authentication {
|
This is part of https://bugzilla.redhat.com/show_bug.cgi?id=1444398. The bug thread is a bit distracted by other issue, hopefully this can help cut to the chase:
usename
is described inAPI/EXTRA_ATTRIBUTES
. However its value is not stored in theoptions
hash, but in the nativeAuthentication
model attributeuserid
.UI has no information to link the two and so when rendering an Edit page, UI can't populate the field with existing value.
So we need a mechanism to bridge them. (For this particular issue, the
username
is theAccess Key
in the screen shot.)@mzazrivec @Fryguy @blomquisg
cc @jntullo
The text was updated successfully, but these errors were encountered: