Removal of OAuth2 stuff from CLI

[AlanCoding]

SUMMARY

Stuff this does

• remove CLI login subcommand
• remove the --conf.token option from the CLI
• remove applications and tokens as resources in CLI, and from import/export
  • bleeds over into the collection, as applications is duplicated in options for collection module
• cascade delete some supporting code in the awxkit library

Ping @gravesm

ISSUE TYPE

• Breaking Change

COMPONENT NAME

• CLI

COMPONENT NAME

• API

[AlanCoding]

Highly related to: #15623

[AlanCoding]

Can't get verification from integration tests due to unrelated issues.

CI failures I have addressed in other open PRs. Marked as ready for review, otherwise, merge blocked on totally unrelated stuff.

[PabloHiro]

I did not remove the applications module from the Collection PR. I thought it was used for more purposes apart from Oauth. Is it not?

[AlanCoding]

I didn't think applications serve any purpose other than for creating tokens. IMO, the tests seemed to reflect this. It's not impossible that I'm wrong, but it seemed relatively clear even from reading the issue for this PR.

[hakbailey]

Just double checking to be thorough, should we remove any of the following?

• Token_Auth class in /awxkit/awxkit/api/client.py
• Reference to OAuth2AccessToken in /awxkit/awxkit/awx/utils.py
• Reference to load_authtoken() function in /awxkit/awxkit/scripts/basic_session.py
• Usage of token in /awxkit/awxkit/ws.py

[AlanCoding]

@hakbailey thanks, these are good suggestions. However, I have been trying to follow the de-referencing cascade from removing those, which goes deep into the fixture structure of integration tests. This gets a little crazy. My head is spinning from the distinction of v2.load_session() and v2.connection.login(), and if the distinction between those should remain after removing tokens.

I deleted the method in awxkit

def uses_sessions(connection):
    session_login = connection.get(f"{config.api_base_path}login/")
    return session_login.status_code == 200

But this is really my critical point of uncertainty. Why would, or would not, the login endpoint give a 200 code? I thought this would have been part of the recent resource-server work, but no, the method appears to be positively ancient. Previously, it should have always given a 200.

I'm thinking perhaps this goes too far, since AWXKIT_SESSIONS is its own independent configuration. You could use a session, use basic auth, or use a token. The session/not-session is still valid? I think...

[AlanCoding]

@hakbailey I pushed a commit that carries out your suggestions. This isn't super-trivial, because there were other method references beyond just the things you mention, and there are many corresponding integration test changes that also cascade from those.

[hakbailey]

This looks good to me assuming the integration test updates worked...

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud