Forum Discussion
I havent actually used the OAuth v1.0 config settings, but if a specific field in ReadyAPI! requires a URL then im guessing that these fields are defined in the rules as resolvable....i.e. you need these values from remote servers (im guessing its very similar to OAuth v2.0 which i have used before now)
Just so youre aware, its a bit of a fallacy to compare Postman to ReadyAPI! for certain things and im guessing this is one of those things.
As another example: the RFCs describing the different http methods/verbs that can be exercised in a REST request define a GET request as synonymous with an SQL SELECT request and doesnt include a payload. The RFC even suggests changing the method to POST if a payload is needed. ReadyAPI! doesnt by default support including a payload with a GET request (im guessing cos of what the RFC says), whereas Postman does support adding a payload to a GET request because the functionality in the tool isnt as tightly coded/constrained as ReadyAPI!
N.b. Smartbear recently provided a config change that enables a payload field for a GET, but this is not the default config setting.
I suggest you read up on OAuth functionality and the back and forth processing that occurs. This will allow you to understand/appreciate why certain fields are URLs.
What im suggesting is that the ReadyAPI! functionality is actually working "as required" but youre misinterpreting how it should actually work.
Cheers,
Rich
Hi richie,
I'm sorry if I have offended here anyone by comparing Postman with ReadyAPI.
I have been initially using ReadyAPI in my project, but when I found that I was unable to create tokens for OAuth 1.0, I had to move to Postman.
I also tried importing the request from Postman for OAuth 1.0, the request was not working. So I'm using 2 tools in my project- Ready API for OAuth 2.0 and Postman for OAuth 1.0.
I'm trying to automate everything in one tool. So I want this feature to be there in ReadyAPI.
Also, I would read the back and forth functionality why only URLs are required.
But if my project comes up with this kind of requirements, then I think whichever tool I'm using should support all the requirements.
This is the basic expectation that I have. After all, I have bought the license for it.
Regards,
Jagruuti
- richie5 years agoCommunity HeroHahaha!
Offend me? Youll have to try a lot harder than that fella.....in fact, most people that know me would say im pretty much unoffendable!
I appreciate that you want the tool to be able to exercise your requirements but if youre not using the tool in the method the RFCs and other supporting sources proscribe (when the tool has been coded to comply with those RFCs) then you can hardly blame the tool!
The fact that youre developers have just given you strings to input to help you out, just doesnt work in this situation. The OAuth functionality is configured for your to obtain those values yourself...which is how id suggest most people would need the functionality to behave.
I should highlight that you can still exercise apis using OAuth without using the OAuth functionality cos ive had to do this before myself (similar situation to you....my project didnt provide me with what i needed) so i setup the individual REST calls of the back and forth processing of the OAuth myself.
Just to be clear. Im not a Smartbear employee!
Nice one,
Rich- Jagruuti5 years agoContributor
Hi richie,
Can you explain to me how I can exercise the API's having OAuth 1.0 without using the OAuth functionality of ReadyAPI?
And how do you set up the individual REST Calls of the back and forth processing of the OAuth?
Thanks and Regards,
Jagruuti
- richie5 years agoCommunity HeroHey Jagruuti,
To setup requests instead of relying on the OAuth functionality you need to replicate the back and forth processing that occurs during the OAuth. Thats it really.
So youll need to identify the grant type scheme your OAuth is using, the 3 or 4 different endpoints that are providing the OAuth tokens, etc. you need and youll need to ensure grab each of the tokens etc. provided by each of the different endpoints.
Its a bit of work. I had to do this twice....one OAuth process required 8 different requests and the other time there were 16 REST requests (albeit both those used a customised, ridiculously complicated bodge of an OAuth process). Best thing would be to speak to dev to confirm all the endpoints/auth/methods/payloads for each request.
As i said, it is entirely possible, but id like to highlight one point before you start. In "live", the genuine OAuth process would be used and so your client app would need to resolve all those static values dev have provided you anyway.
Perhaps it would just be easier to use the OAuth processing?
Mind you....if dev have provided you hard coded values then perhaps the OAuth processing hasnt actually been coded yet. If thats the case then settimg up the individual requests wont work.
If this is the case, you have 1 other option and tbh, i think this would be the easiest. The fact that dev provided you with some hardcoded values means unlike most OAuth, you Authorization header value you need to pass onto all your REST requests is static/constant. The back and forth that OAuth performs is all about building up to get the access/bearer tokem you need for your REST requests you need to test.
So! Go into postman and submit your OAuth request (with those static values dev gave you). At this point, once the request is submitted, have a look at the Authorization http header value. Copy that and paste it into your REST test steps Authorization header (i.e. hard code the value).
That should work nicely. Sorry. I shouldve come up with this first. This wont solve the problem once your OAuth processing has been coded, but once it has bren developed youll be able to use the OAuth functionality im ReadyAPI!/SoapUI anyway!
Ta
Rich
Related Content
- 5 years ago
- 4 years ago
- 4 years ago
Recent Discussions
- 22 days ago