Added flag to make wrapping username with domain optional (to support basic auth).

[OrangeAndGreen]

Technical Summary

Added a dedicated BasicAuth class that the Android code can use to perform basic HTTP auth without any additional wrapping. The Android code does a type check on the AuthInfo to determine what credentials to send up, and other sub-classes involve additional steps that don't work for basic auth.

Safety Assurance

Safety story

Simply adding a class here for commcare-android to use.

Automated test coverage

No new tests.

Special deploy instructions

• This PR can be deployed after merge with no further considerations.

Rollback instructions

• This PR can be reverted after deploy with no further considerations.

Review

• The set of people pinged as reviewers is appropriate for the level of risk of the change.

Duplicate PR

Automatically duplicate this PR as defined in contributing.md.

[shubham1g5]

@OrangeAndGreen Where can I see the corresponding Android code for this PR ? Basically want to see what changes in Android code necessitate the need of basic auth class as it looks exactly same as ProvidedAuth .

[OrangeAndGreen]

Of course, that makes sense! The relevant change is in the dv/connect_id branch of commcare-android. The usage is in HttpUtils.getCredential, where the case for ProvidedAuth wraps the username using buildDomainUser(). I added a case for BasicAuth that passes the username straight through.

[shubham1g5]

That makes sense, one other way to do that would be to just add a wrapDomain flag to the current auth class defaulting it to true. I don't have a strong preference between the two but if we want to add another class which is potentially just for connect, I think we should have it in a connect specific package and probably rename it to ConnectAuth or something like that which makes it obvious this should not be used for normal CC pathways.

[OrangeAndGreen]

Ah, I think I like your wrapDomain approach better! It solves the problem, keeps it more generic, and also prevents the need for a new class. I'll make that change.

[OrangeAndGreen]

Ok, change made and ready for review.

[shubham1g5]

Thanks Dave this looks good. Couple things around core PRs -

1. It's a good practice to PR the corresponding Android/Formplayer repo change along with the Core changes and cross-request them to each other. That way we have a history of why a change was made in core.

2. We need to duplicate all the core PRs across formplayer and master. The process for that is outlined here.

[OrangeAndGreen]

cross-request: dimagi/commcare-android#2660

[OrangeAndGreen]

Duplicate this PR