Forum Discussion

Gurbakhsish's avatar
Gurbakhsish
Occasional Contributor
9 years ago

How to manage different auth profiles per environments for different roles in REST api project

Hi, 

 

I am trying to use environment settings in my project, but it seems that there is a tight coupling between environment and Auth profiles. My project scenario is,

 

1. There are four different roles/permissions in the project. All the REST apis can be called using all the four roles(email/password combination) but some APIs will return 403 which is needed to be tested.

2. I also have to manage the project for different environments, currently three.

 

Now what I have setup so far,

1. I have setup some project level custom properties like baseUrl, which has a default value for endpoint/domain name. I use ${#Project#baseUrl} in the endpoint for REST request. This is working fine.

2. Now, I tried setting up a couple of environments settings. I have local, qa. and I have provided the different values to baseUrl for different environments, which is also working fine.

 

Actual issue being faced,

Now when I am looking at my REST requests under Projects tabs, the Authorization is overridden as "No Authorization" and the dropdown is disabled. I want Authorization profiles to be independently set, without managing them through Auth Repository because one testcase will be run for all the four roles/permissions in a loop under one testcase.

 

I hope, I have made my scenario and requirement quite clear.

 

Thanks in advance

7 Replies

  • rdls's avatar
    rdls
    Occasional Contributor

     

    1. Created Generic project
    2. Added suite, test case, and HTTP request with default names
    3. Added 3 Project-Level properties: URL, Username, Password
    4. Clicked Environments, created Development env and selected Copy endpoints & credentials from the project
    5. Clicked Environments, created Staging env and selected Copy endpoints & credentials from the project
    6. Went to HTTP Request Test step (while Environment was set to Default) and clicked Auth tab
    7. Set Authorization to Basic. Note: in the HTTP Request Properties section on the Navigator pane, Authorization Type was set to Global HTTP Settings
    8. Filled in username/password/domain fields with ${#Project#Username}, ${#Project#Password}, ${#Project#URL}
    9. Went to Environment drop down and switched from Default to Development
    10. The Auth tab went grey, Username/Password/Domain fields disappeared, Authorization was set to No Authorization, and the drop down was disabled. Authentication Type on the Navigator pane was set to No Authorization (this happened when I clicked on the Global HTTPS Value). 
    11. Switched Environment drop down from Development to Staging and the Auth remained greyed out. Authentication Type on the Navigator pane was set to No Authorization.
    12. Switched Environment drop down from Staging to Default and the Auth tab fields all appeared. Authorization Type drop down worked, and the Username Password Domain fields were editable. I clicked on Authentication Type on the HTTP Request Properties tab under the Navigator pane, and it changed from No Authorization to Global HTTP Settings.

     

    I used a generic URL and User/pass values for this test, so you might not see a difference in the Http Raw responses.  The writeup above mainly shows the behavior in SoapUI NG Pro.  The issue is more evident using our own web services as we are posting/deleting files to file respository and the posting/deleting does not happen when the No Authorization issue blocks our credentials from being sent. 

     

    I’ve tried importing my work project to a different employee’s machine, and she has tried on 1.3.1, and 1.5.0.  She is able to get the authentication working on 1.3.1 but not 1.5.0, and the rest of us are using 1.5.0. 

     

    I’m about to try downloading and installing the latest nightly build from https://support.smartbear.com/downloads/readyapi/nightly-builds/#_ga=1.187228718.724436189.1452738956.  I will report back if this fixes things for me or not. 

    • nmrao's avatar
      nmrao
      Champion Level 3
      Thank you for the details and the project.
  • rdls's avatar
    rdls
    Occasional Contributor

    I found a quick & easy workaround for this issue that only adds a couple of steps to test different environments.

     

    1. Create your Dev/Staging environment properties using the Environments utility (you've probably already done this).

    2. From the Environments utility, save each environment's set of properties to the property file you are creating and name the file according to the environment (DevProps or StgProps).

    3. Go to your project and set the environment dropdown to Default Environment.

    4. Go to your project's project level and import the Dev properties file you saved to the project (be sure Create Missing Properties is checked). Your whole project will now be aimed at dev, and the Auth tab will retain the Authorization Type you first set up and all options will be enabled. Note: for my setup, I imported them to the Custom Properties tab.

    5. To test on Staging, leave the environment dropdown set to Default Environment. Import the Staging properties to the project level.  Your project will now be aimed at staging, and the Auth tab will still work properly.

     

    Switching environments will now be a matter of simply importing the dev or staging properties files at the project level.   

    Note: If you add new environment properties, be sure to still do that using the Environments utility and save off new Dev/Stg properties files from the utility (I would just overwrite the existing *Props file).

     

    If you end up needing to roll this into a CI/CD system, you could simply clone the project to make a Dev and Staging version of it until Smartbear fixes the Auth Tab Environment Switching issue.   

     

    Once SmartBear fixes the issue, you can simply start using the Environments dropdown again as normal.  

     

    This is working for my team, if anyone has a better idea, please share. 

    • nmrao's avatar
      nmrao
      Champion Level 3
      Glad to know and thank you for sharing the details.
  • rdls's avatar
    rdls
    Occasional Contributor

    I'm seeing the same issue with Authentication Type being overridden to No Authorization.  I'm using Ready API 1.5.0 64bit on Windows 7 64bit, btw. 

    My Enviornments are: Default enviornment, Devlopment, and Staging.

     

    Default works, but Dev and Staging get overridden.  I've tried various fixes: creating a new project then mirroring the scenario, manually editing the XML to force Preemptive, adding/setting an Authentication Type property at the Enviornments and Project level, but nothing seems to work. 

     

    I found these two other threads from 2014 and it seems this issue has been going on since then:

    http://community.smartbear.com/t5/SoapUI-NG/Can-t-change-request-authentication-type-in-SoapUI-5/m-p/40667/highlight/true#M20660

     

    http://community.smartbear.com/t5/SoapUI-NG/Reg-Auth-Compatibility-Issues-with-soapui-5-0-0-and-4-x/td-p/40779

     

    Please help!

    • nmrao's avatar
      nmrao
      Champion Level 3
      Can you just provide some sample project along with steps to reproduce the issue?
  • rdls's avatar
    rdls
    Occasional Contributor

    I tried the latest snapshot build (win 64bit), and this issue is present in that version as well.