Igor Cernopolc - Http authentication in automated testing - presentation script
0 likes529 views
This presentation discusses problems with handling HTTP authentication dialogs during automated web testing and various solutions. The main problems are that the dialog is non-HTML and each browser implements it differently. Several workarounds are presented, including embedding credentials, using browser profiles, cookies, addons, and external automation tools. The presentation then details the speaker's solution which uses Selenium for web automation combined with AutoIT to handle the non-HTML dialog via separate threads. Some limitations are discussed but the solution is presented as a valid approach to overcome problems with HTTP authentication dialog handling during automated testing.
Igor Cernopolc - Http authentication in automated testing - presentation script
- 1. Presentation script Slide 1 - HTTP authentication in automated testing – problems and solutions Igor Cernopolc igor.cernopolc@gmail.com This subject has its roots in my personal experience of more than 4 years in testing field. I will describe the problems that were encountered, and solution found during testing of a web app that required HTTP authentication. Slide 2 – HTTP Authentication dialogs Here you can see examples of how this dialog looks. Slide 3 - Usage HTTP Authentication is s solution easy to implement and at the same time relatively secured. That is why it is often used in intranets, back office application, in the cross domain authentication. In our testing task, depending of the app specifics, we can often get to deal with HTTP authentication dialogs. Handling it is no issue for a manual tester, but problems appear when we have to write automated tests for our app. Let’s see what the biggest problems that this dialog is raising are. Slide 4 - Main problems The first and the most visible problem raised is that the HTTP authentication dialog is a non-HTML dialog. There are few web testing, free tools that can handle this kind of dialogs. Let’s take a classic example, Selenium; it is almost powerless in handling non-HTML dialogs. Slide 5 - Main problems Another problem is generated by the requirement of an application to be supported by the majority of current browsers. Each browser vendor implements his own HTTP authentication dialog style, in order to respect browsers style and add new functionalities. In this way, we have lots of implementations for the same authentication method, each of them being more complex and hard to be tested than others. Slide 6- Main problems In conclusion, we have to deal with a non-html dialog that has more appearances that we would like. Which is the consequence of these issues? Slide 7 -Consequence There are too many workarounds for handling a HTTP authentication dialog during automated testing. The most used solutions will be presented in the next slides. Slide 8 - Solutions The first and the most used solution is to embed credentials in http request header. An easy to implement solution, but there
- 2. are browser that don’t support it anymore and it does not work in all cases. Slide 9 - Solutions A valid solution for Firefox is to use profiles. Tester can create a specific profile with embedded credentials and settings, and load this profile every time it is needed. An interesting solution, but limited only on Firefox. Slide 10 - Solutions Another solution our friend Google suggests us is using specific cookies when loading the page, but most of the application the need to be secured don’t allow this type of connection. Solutions presented until now can be considered browser based. There also some external solutions that will be described in the next slides. Slide 11 - Solutions One option is to use add-on, Firefox add-on AutoAuth specifically. Tester can save his credentials for a specific domain and each time an http authentication dialog appears, it is handled by the add-on. Sounds very well and simple to use, but the same as profiles, it is limited to Firefox. Slide 12- Solutions Another identified solution is more generic and has a specific approach on the problem. Java Robot class can simulate keyboard typing into fields, acting like a human interaction with the app. In this way the solution is not a browsed related one, it can be used on any browser. One big disadvantage can be found for it, there is no way to connect to the dialog, the input is done blind and we cannot be sure that we type our credentials into correct fields. Slide 13- Solution The last solution found that deserves to be mentioned is using external application like AutoIT or Siculi. These are designated for GUI testing and general scripting. They can handle any non-html dialogs including HTTP authentication or Load File. Slide 14 – Smile As you can see, the world is not so dark and even the hardest problems have solutions. Slide 15 – Toolbox What we can do when we need a solution to work on all current browsers? We can pay a couple of hundreds or thousands euros for a dedicated solution, or we can make our own one. Using a right combination of tools can be a good choice and save you big money. Slide 16 - 18– My Solution In the next slides, a solution implemented by me is presented. At the company I work, the most used tool for web testing is Selenium (Webdriver) with tests written in java. All I had to implement is a module that will handle the non-HTML dialogs. AutoitX was my choice. It is a library that lets the tester to write and call autoit command directly from java code. The combination formed from Webdriver, Java and AutoitX is my solution for our problematic HTTP authentication dialog, solution described in the diagram.
- 3. Slide 19-20 – My Solution Let’s start with a simple test case: Open and login to a web page Verify the login was successful by validating a page element Our solution is interesting from the start, because the problem itself is interesting. We have to deal with a login dialog that appears on page load. Before implementing the solution, selenium was freezing waiting for the correct page response until timeout was reached. Slide 21-22 – My Solution The on load authentication dialog we treated by using 2 threads of execution. In one method we combined the page load and handle of authentication. The most important thing to mention is that user need to start the helper thread, the one that will handle the dialog, before opening the desired page. Slide 23-24 – My Solution All the helper thread is doing is to wait for the authentication dialog to appear and when it was found, to enter the provided credentials and click OK. Slide 25-27 – My Solution After the authentication dialog is accepted, browser renders the page and in the main thread, selenium finishes the load method, closes the helper thread and passes execution to next verifications. Slide 28 – Limitations We mentioned some limitations for all the solutions described in this presentation, our solution is also not limitations free. Autoit is a windows based app, in order to run on other OS, another approach should be found. Another limitation was found during distributed test runs. Autoit is an external tool and running through Selenium grid is problematic. The local instance of autoit is called instead of the remote ones. Slide 29 – Limitations Even if we have limitations in our solution, if we need a fix, and are perseverant, we can try to use Siculi in order to fix the OS dependency. For the second limitation, theoretically, we can use external autoit script calls and not the autoitX calls, or mirror the local workspace on remote machines. Slide 30 – Conclusions Don’t be afraid of using multiple tools when it is required. Combine and innovate and you will succeed. Thank you for attention If you are interested to get a demo app containing the presented code and solution, please contact me: igor.cernopolc@gmail.com