RESTinstance
RESTinstance copied to clipboard
Support of requests sessions
The underlying request library supports the use of sessions. Do you think it would be feasible to provide a session parameter to the library?
Thanks for asking this! I am leaving this open, in case we get some discussion on this.
To everyone: Do you have an use case in mind, regarding API testing, where sessions would be beneficial or provide additional value?
Edit: @niecore likely means sessions as they are provided by Robot Framework RequestsLibrary (https://bulkan.github.io/robotframework-requests/#Create%20Session, which uses Python requests' sessions underneath) - correct me if I am wrong.
@asyrjasalo My company requires a valid OAuth2 session to access our web APIs. We currently use the RF ExtendedRequestsLibrary (link below) so that the session cookies can be passed to each request after authentication.
However, the library hasn't been maintained in over 2 years and I really like the improvements/advances your library has made in API testing with RF (schemas). And so switching to RestInstance at some point would be ideal if the library supports OAuth2 sessions.
I think authenticated sessions for API level testing is a requirement for Test Engineers working in Banking/Medical software. Or any software testing that deals with sensitive data accessed via an API.
https://github.com/rickypc/robotframework-extendedrequestslibrary
+1 to the previous post. We also need OAuth2 token to be passed with every request to API in our API tests. Would be nice to have that supported.
Most of resources need to request such as login first, then could test the other resources, if can support session it will be easy to write tests.
We are currently looking into creating automated tests for our software and currently we don't really have support for authentication headers such as OAuth2 or Basic Authentication. Therefore we are limited to the use of authentication cookies. We have working tests with the HTTP library (Requests), but I really would like to use this REST library...
And yes, this is also a medical application that doesn't support anonymous users....
Hello,
So any traction on this or just still leaving it open? There does seem to be some interest in supporting Sessions but would it be a difficult task? Or finishing the examples/documentation as to how to handle Headers and authentication?
Thanks for your effort.
+1 for OAuth support. As I mentioned in another issue of this repo (at least for the browser based flows of) OAuth the support of application/x-www-form-urlencoded request headers is required.
How would this work? I don't think I am too familiar with the topic.
Would any of you mind providing a high-level proof-of-concept how this would be used in a test suite. The example does not have to be complete.
Thanks for all the comments.
Alas, no high-level proof of concept. But I still would like to be able getting an OAuth token via the RESTinstance lib. Our company keeps the same token alive for a limited period of time in the test environment. So it is possible to use the token in a subsequent get request without having to open a session.
I believe I'm not directly answering the question here, but I'm working in an environment that has to get an authentication token from a server that requires authentication. What works for my project was merged with #113 and my workflow is the following:
- Import library with
Library REST <endpoint> ssl_verify=False
- Get certificate file from server without authentication
- Authenticate (i.e. get auth token)
- Use
Set SSL Verify
(merged with the PR) to set the SSL verification to the retrieved cert file instead ofFalse
- Use
headers={"Cookie": "authtoken=${AUTH_TOKEN}"}
in my followingPost
keyword(s). This could be set withSet Headers
keyword as well to set the headers for the whole suite, but my test doesn't require that as it continues using other services
I hope this helps someone, but I agree that proper session support would be nice.
Hi Aleksi,
Thanks for your reply. I might perhaps fail to understand your solution but it seems to me that my problem lies in: get certificate file and authenticate. That is something that works quite well with Postman. But when I try to emulate this in an RF script like below, I get an unauthorized error. The server fails to account for the content-type of he request. There seems to be no way for the REST command to let the server know that the request body is not json.
Get OAuth Token REST [Arguments] ${url} ${client} ${secret} Set Headers {"Content-Type" : "application/x-www-form-urlencoded"} &{body} Create Dictionary client_id=${client} ... client_secret=${secret} ... grant_type=client_credentials ${resp} Post https://${url} body=${body} Log To Console Token=${resp}
Hi @etienneroijen,
The body
argument only supports JSON. RESTInstance 1.1.0 introduced data
(same as --data
in curl
) argument which supports other data formats. Could you try using that instead of body
?
EDIT: As an example, it can be used just like any other argument in Robot Framework. E.g.
Get Certificate
[Arguments] ${endpoint} ${client_name}
# First create a binary file with ${client_name}, which then produces a file called ${client_name}.csr
# ...
Post ${endpoint} data=${client_name}.csr headers={"Content-Type": "application/pkcs10"}
${cert}= Output response body
[Return] ${cert}
Hi Aleksi,
Is there a description of how to use this in Robot Framework? I tried to implement your suggestion, but I cannot get it to work. The lib documentation I use [https://asyrjasalo.github.io/RESTinstance/] has no reference to a data parameter in connection with a post request.
Kind regards, Etienne
Oh, you're absolutely right! It doesn't mention the data argument. We'll release new documentation soon! Sorry for that.
It should work with a dictionary, bytes, or file. If it doesn't I need to take another look at the implementation.
I tried this
Settings
Library REST proxies=&{PROXIES} ssl_verify=False
Keywords
Get OAuth Token REST
[Arguments] ${url} ${client} ${secret}
Set Headers {"Content-Type" : "application/x-www-form-urlencoded"}
${body} Set Variable client_id=${client}&client_secret=${secret}&grant_type=client_credentials
${resp} Post https://${url} data=${body}
Log To Console Token=${resp}
But I keep getting the same error: Bad credentials. I checked it against a Postman post request with the same parameters. That gives me a nice token back. [ Actually I checked it against two sets of url and credentials for two different environments. ]
Regards, Etienne
Oops, if forgot to check the version of the lib in the VDI environment we use . . That might be the trouble, although I get no formal error for using the data parameter.
Etienne
Strangely enough when I do a pip install --upgrade RESTinstance I get lots of information messages, starting with: Requirement already up-to-date: RESTinstance in c:\python38\lib\site-packages (1.0.2). But you mentioned version 1.1.0 ?
Etienne
Yes, 1.1.0 was released a month ago as you can see from PyPI.
We have Python 3.8 installed. Could that be the reason pip install says that all requirements are already satisfied? After install the RESTinstance version stays at 1.0.2.
Etienne
Python version 3.8 shouldn't be a problem. I have Python 3.8 as well in my local machine and it installs it just fine. Can you try installing with --no-cache-dir
or --force-reinstall
or even just by uninstalling it and then installing it again?
Hi Aleksi,
I did install the latest RESTinstance lib. Sad to say that now my robot command is no longer available. I did it twice on a locally provisioned VDI with command pip install --upgrade RESTinstance and after setting the appropriate proxy.
'robot' is not recognized as an internal or external command, operable program or batch file.
Any idea? Below is the response of the install.
Regards, Etienne
Collecting RESTinstance
Downloading RESTinstance-1.1.0-py2.py3-none-any.whl (28 kB)
Requirement already satisfied, skipping upgrade: pygments in c:\python38\lib\site-packages (from RESTinstance) (2.6.1)
Requirement already satisfied, skipping upgrade: strict-rfc3339 in c:\python38\lib\site-packages (from RESTinstance) (0.7)
Requirement already satisfied, skipping upgrade: jsonpath-ng in c:\python38\lib\site-packages (from RESTinstance) (1.5.1)
Requirement already satisfied, skipping upgrade: rfc3987 in c:\python38\lib\site-packages (from RESTinstance) (1.3.8)
Requirement already satisfied, skipping upgrade: requests in c:\python38\lib\site-packages (from RESTinstance) (2.23.0)
Requirement already satisfied, skipping upgrade: GenSON in c:\python38\lib\site-packages (from RESTinstance) (1.1.0)
Requirement already satisfied, skipping upgrade: tzlocal in c:\python38\lib\site-packages (from RESTinstance) (2.1)
Requirement already satisfied, skipping upgrade: jsonschema in c:\python38\lib\site-packages (from RESTinstance) (2.5.1)
Requirement already satisfied, skipping upgrade: docutils in c:\python38\lib\site-packages (from RESTinstance) (0.16)
Requirement already satisfied, skipping upgrade: flex in c:\python38\lib\site-packages (from RESTinstance) (6.14.1)
Requirement already satisfied, skipping upgrade: pytz in c:\python38\lib\site-packages (from RESTinstance) (2020.1)
Requirement already satisfied, skipping upgrade: robotframework in c:\python38\lib\site-packages (from RESTinstance) (3.2.1)
Requirement already satisfied, skipping upgrade: ply in c:\python38\lib\site-packages (from jsonpath-ng->RESTinstance) (3.11)
Requirement already satisfied, skipping upgrade: six in c:\python38\lib\site-packages (from jsonpath-ng->RESTinstance) (1.14.0)
Requirement already satisfied, skipping upgrade: decorator in c:\python38\lib\site-packages (from jsonpath-ng->RESTinstance) (4.4.2)
Requirement already satisfied, skipping upgrade: idna<3,>=2.5 in c:\python38\lib\site-packages (from requests->RESTinstance) (2.9)
Requirement already satisfied, skipping upgrade: certifi>=2017.4.17 in c:\python38\lib\site-packages (from requests->RESTinstance) (2020.4.5.1)
Requirement already satisfied, skipping upgrade: chardet<4,>=3.0.2 in c:\python38\lib\site-packages (from requests->RESTinstance) (3.0.4)
Requirement already satisfied, skipping upgrade: urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 in c:\python38\lib\site-packages (from requests->RESTinstance) (1.25.8)
Requirement already satisfied, skipping upgrade: validate-email>=1.2 in c:\python38\lib\site-packages (from flex->RESTinstance) (1.3)
Requirement already satisfied, skipping upgrade: jsonpointer>=1.7 in c:\python38\lib\site-packages (from flex->RESTinstance) (2.0)
Requirement already satisfied, skipping upgrade: click>=3.3 in c:\python38\lib\site-packages (from flex->RESTinstance) (7.1.1)
Requirement already satisfied, skipping upgrade: PyYAML>=3.11 in c:\python38\lib\site-packages (from flex->RESTinstance) (5.3.1)
Installing collected packages: RESTinstance
Attempting uninstall: RESTinstance
Found existing installation: RESTinstance 1.0.2
Uninstalling RESTinstance-1.0.2:
Successfully uninstalled RESTinstance-1.0.2
Successfully installed RESTinstance-1.1.0
Do you have Robot Framework installed and in PATH? Can you also try python3 -m robot
or python3 -m robot.robot
? Upgrading RESTinstance shouldn't affect your robot installation in any way.
I agree, it shouldn't. But yes I had Python38 installed. To be sure I logged off from the VDI, logged in again [which creates a new installation of the VDI for me], then ran a script [which went fine], then upgraded the RESTinstance lib and went back to the script. Again robot was not recognized. I ran your commands. Now Python3 is also not recognized.
Could it be that the installation ruins the necessary path configurations?
Regards, Etienne
I see that the path is still pointing in the right direction: C:\Python38 and C:\Python38\scripts.
Actually python3
is not a command for Windows. It's just python
. Sorry for the confusion!
It looks like from you pip install that Robot Framework is installed under c:\python38\lib\site-packages
. I haven't used Windows for work purposes in a few years so I'm not actually sure if it will place the executable in C:\python38\scripts
or not (e.g. Scripts
vs scripts
, don't know if it's case sensitive). I would double check that the PATH is set correctly and that Robot Framework is in PATH.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.