Auth option prompting happens waaaay to early in the default os-client-config flow, we need to defer it until adter the commands have been parsed. This is why ClientManager.setup_auth() exists, as it is not called until the first attempt to connect to a server occurs. Commands that do not require authentication never hit this. Also, required options were not being enforced. By doing this we handle when no authentication info is present, we fail on missing auth-url rather than attempt to prompt for a password (default auth is password). Closes-Bug: 1619274 Change-Id: Ia4eae350e6904c9eb2c8507d9b3429fe52418726 (cherry picked from commit 14dbfe44741b65c9e0514a34669f52de8629b1c0)
We start by fixing this in the already-present OSC_Config class so OSC can move forward. This change needs to get ported down into os-client-config in the near future, maybe even soon enough to make the client library freeze this week. * Add the pw-func argument to the OSC_Config (or OpenStackConfig) __init__() * When looping through the auth options from the KSA plugin look for any that have a prompt defined and do not have a value already, so ask for one. Closes-bug: #1617384 Change-Id: Ic86d56b8a6844516292fb74513712b486fec4442
The split to osc-lib shell lost the detection of --os-token and --os-url to set --os-auth-type token_endpoint Closes-bug: 1615988 Change-Id: I248f776a3a7b276195c162818f41ba20760ee545
Fix argument precedence hack Working around issues in os-client-config <= 1.18.0 This is ugly because the issues in o-c-c 1.19.1 run even deeper than in 1.18.0, so we're going to use 1.19.0 get_one_cloud() that is known to work for OSC and fix o-c-c with an axe. Remove return values for set commands 'identity provider set' and 'service provider set' were still returning their show-like data, this is a fail for set commands now, don't know how this ever passed before... Constraints are ready to be used for tox.ini Per email[1] from Andreas, we don't need to hack at install_command any longer. [1] http://openstack.markmail.org/thread/a4l7tokbotwqvuoh Co-authorioed-by: Steve Martinelli <s.martinelli@gmail.com> Depends-On: I49313dc7d4f44ec897de7a375f25b7ed864226f1 Change-Id: I426548376fc7d3cdb36501310dafd8c44d22ae30
Convert to using ClientManager and OpenStackShell from osc-lib. * Change all internal uses of ClientManager private attributes that are now public in osc-lib's ClientManager. Leave back-compat copies in place in OSC's clientManager so we don't break plugins. * Put some work-arounds in place for changes in osc-lib that we need until a new release makes it through the g-r and u-c change process. * Add a test for Unicode decoding of argv in shell.main() to parallel the one in osc-lib. Change-Id: I85289740d4ca081f2aca8c9b40ec422ad25d302c
When the openstackclient in Python2 passes command line arguments to a subcommand it fails to pass the arguments as text (e.g. Unicode). Instead it passes the arguments as binary data encoded using the current locales encoding. An easy way to see this is trying to pass a username with a non-ASCII character. % openstack user delete ñew No user with a name or ID of 'ñew' exists. What occurs internally is when the user data is retrieved it's it properly represented in a Unicode object. However the username pased from the command line is still a str object encoded in the locales encoding (typically UTF-8). A string comparison is attempted between the encoded data from the command line and the Unicode text found in the user representation. This seldom ends well, either the comparison fails to match or a codec error is raised. There is a hard and fast rule, all text data must be stored in Unicode objects and the conversion from binary encoded text to Unicode must occur as close to the I/O boundary as possible. Python3 enforces this behavior automatically but in Python2 it is the programmers job to do so. In the past there have been attempts to fix problems deep inside internal code by attempting to decode from UTF-8. There are two problems with this approach. First, internal code has no way to accurately know what encoding was used to encode the binary data. This is way it needs to be decoded as close to the I/O source as possible because that is the best place to know the actual encoding. Guessing UTF-8 is at best a heuristic. Second, there must be a canonical representation for data "inside" the program, you don't want dozens of individual modules, classes, methods, etc. performing conversions, instead they should be able to make the assumption in what format text is represented in, the format for text data must be Unicode. This is another reason to decode as close to the I/O as possible. In Python3 the argv strings are decoded from the locales encoding by the interpreter. By the time any Python3 code sees the argv strings they will be Unicode. However in Python2 there must be explicit code added to decode the argv strings into Unicode. The conversion of sys.argv into Unicode only occurs when argv is not passed to OpenStackShell.run(). If a caller of OpenStackShell.run() supplies their own arg it is their responsiblity to assure they are passing actual text objects. Consider this a requirement of the API. Note: This patch does not contain a unittest to exercise the behavior because it is difficult to construct a test that depends on command invocation from a shell. The general structure of the unit tests is to pass fake argv into OpenStackShell.run() as if it came from a shell. Because the new code only operates when argv is not passed and defaults to sys.argv it conflicts with the unittest design. Change-Id: I779d260744728eae8455ff9dedb6e5c09c165559 Closes-Bug: 1603494 Signed-off-by: John Dennis <jdennis@redhat.com>
* Add compatibility for plugin v2 interface removed from osc-lib * ClientManager.is_network_endpoint_enabled() is wrapper for new is_service_available() Change-Id: I6f26ce9e4d0702f50c7949bacfbeeb0f98cddb5d
Some files have execute permission unnecessarily. Change them from 755 to 644. Change-Id: I471ebd1c3d123ad4a7376f7f5996f53f8c2d9b0b
When an exception was caught and rethrown, it should call 'raise' without any arguments because it shows the place where an exception occured initially instead of place where the exception re-raised. Change-Id: I5fb6dea5da7fb6e1e2b339a713c7d37f8c99e407
This changes the scope validation to occur after a token has already been created. Previous flow: 1. Validate authentication options. 2. Validate authorization options if the command requires a scope. 3. Create a token (using authentication + authorization options) 4. Run command. This means that scope was being checked, even if a default scope was applied in step 3 by Keystone. New flow: 1. Validate authentication options. 2. Create token (using authentication + authorization options) 3 Validate authorization options if the command requires a scope and the token is not scoped. 4. Run command. Change-Id: Idae368a11249f425b14b891fc68b4176e2b3e981 Closes-Bug: 1592062