Skip to content
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

Allow to pass username and password keys as parameters for the UserFact attribute #5

Open
Alexei000 opened this issue Nov 14, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@Alexei000
Copy link

This is a very useful library when dealing with older applications that use Windows Authentication.
I was wondering if there is any particular reason why the username, password and domains keys cannot be provided as parameters:

    private readonly string usernameKey = "Username";
    private readonly string passwordKey = "Password";
    private readonly string domainKey = "Domain";

I am thinking about scenarios of testing using multiple users with various roles. This would require a secret file for each of them which is clearly feasible, but not the way Visual Studio treats them (one associated secret file per project).

Is there any reason for this design? If not, I will try to add overloads allowing to pass the keys.

Thank you.

@Alexei000 Alexei000 changed the title Allow to pass username and password keys as parameters for the UserFact Allow to pass username and password keys as parameters for the UserFact attribute Nov 14, 2020
@Alexei000
Copy link
Author

I think an easier way is to use UserFactAttribute(string username, string password, string domain and fetch these using IConfiguration. They can be defined however I want in secrets.json for the development environment and appsettings.json or environment variables when deployed.

My goal is to allow the tests to run both in the development environment and in some pipeline.

Anyway, I am looking forward to any suggestions.

@kurtmkurtm
Copy link
Owner

Hi @Alexei000,

When I initially built this it was for a relatively simple single user scenario.

That said, I like your idea of having the keys passed in.

I think the only consideration with adding another overload is that it would have the same method signature as the existing one for the inline credentials. It would require another parameter to differentiate between the inline credentials and the configuration keys.

Did you end up trying to add another overload?

If so, I'm happy to take a look at a PR if you want to open one.

@kurtmkurtm kurtmkurtm added the enhancement New feature or request label Nov 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants