Evaluate potential improvements

[rlaurindo]

As K6 studio is design and more user-friendly for people don't have much knowlogde about programming. It could make available a specific configuration to authentication as Jmeter has. When we may provide our username and password to authenticate in our application easily.

[rlaurindo]

[Llandy3d]

Hi!
Could you please expand on your use case? I would like to better understand where this would be useful 🤔

The current intended workflow is for you to record the whole workflow, including the login, from the browser recorder so that your generated script has already the login information.
We also have the Parameterization Rule to change a specific value if needed

[rlaurindo]

That's where the problem lies! My application using SSO generates an Authorization like this when I access it through the main page, for example:
oXcwdaADCgEBoloEWE5UTE1TU1AAAwAAAAAAAABYAAAAAAAAAFgAAAAAAAAAWAAAAAAAAABYAAAAAAAAAFgAAAAAAAAAWAAAABXCiOIKAGNFAAAAD2qLmCG1NE/xy6d2iIFiXlijEgQQAQAAAKqwTYmhGhc6AAAAAA==.

The issue is that I don't have programming knowledge, and I don't see many articles about how to use authentication within JavaScript. From the documentation, I was able to use the NTLM example directly in a JS script in VS, but in K6 Studio, I don't find it practical to parameterize authentication. Regarding authentication, JMeter has the practicality of injecting a username and password for authentication.

In many applications, authentication is a recurring step across various tests. Instead of recording the login process every time, users could configure authentication (e.g., username/password) once and reuse it across multiple tests.
Many modern applications use OAuth, API tokens, or custom headers for authentication. A specific configuration for these methods could reduce the learning curve for users unfamiliar with scripting such flows.

[Llandy3d]

sorry for getting back so late, I see what you mean.
For those scenarios what we have in k6 Studio is the Correlation rule that let's you define where to take a value from and where to replace it when running the script, the possible issue here is that it's a manual operation as of now defining how it should behave, so if authentication is recurring or different, it means you might need more than one.

This probably needs to be investigated further to see how we can make it simpler in the scope of auth to use, I do see the comfort that "letting the tool handle auth for me" would bring 🙇