HTTP Request Error with Username/Password Parameters

studio
http

#1

There is probably away around this but I need to do an HTTP Post with username and password parameters. It works fine in the wizard but once the activity is added, it breaks. Here are the screenshots for the post, preview of response (which is correct), and final activity error.

How can I get around this?


#2

It can sound stupid but you can build a local html page with a form yhat does the post to the post url and set up the robot to complete it and push submit. …


#3

It seems that you have a naming conflict in your workflow.
Could you go through your variables and arguments and rename the ones that are named the same as your request parameters (Username and Password)?


#4

Hi @andrzej.kniola.

There really isn’t a workflow. I just added that one activity to a test project to see if I could access a resource with the REST api.

Like I said it works in the wizard but as soon as I click on Okay, the HTTP Request activity shows the errors. My suspicion is that the Username and Password parameters I need to pass are in conflict with the built-in Username and Password parameters for Simple Authentication.

Does that sound like a reasonable assumption?

@crimaru Thanks for the suggestion. That would work but as you hinted, probably not the best solution.

Right now I’m looking at just building the code in VB and using the Invoke Code activity but sure wish someone has a better solution.

I’m open for more suggestions.

Thanks all.
Troy


#5

Actually that could be true.
And it’s not only HTTP Request:

@qateam , @Cosmin_Ion_Nicolae
RuntimeArguments?


#6

Bummer. The HTTP Request is a nice activity with a really neat wizard BUT integrating all the auth options may be overkill for a single activity.

Especially with the included arguments “username” and “password” which I would venture to say need to be called as parameters with many REST APIs. For me it returns a security token that has to be used in all subsequent requests so I’m stuck until I find a workaround.

Thanks for looking @andrzej.kniola and tagging the qa team.


#7

So I don’t leave this hanging for future readers…

In my case with the HTTP Request the parameters I was sending to the end point were not case sensitive so I was able to change my parameter names to lower case which were then unique and error free.