browser
No Content being Loaded in Single-Page Web Application
A single-page web application was being served by a web server and was supposed to interact with another web server to load content like posts, comments and ratings. Although the web application could be loaded and the overall structure was visible, no content was being displayed.
Looking at the console with Firefox's inspector tool revealed that the request to the other web server, an API proxy, was blocked by Firefox because the request was cross-origin and the other web server did not explicitly allow such a request. The initial solution was to allow any cross-origin requests by adding a `Access-Control-Allow-Origin` header with `*` (any origin) to any responses of the API proxy. This solved the problem but was not ideal. The better solution would have been proxying the web application through the API proxy too, so that the default – same-origin policy – would apply again.
Taggings:
Bypassing “cross-origin request”-errors on testing a web service locally
Developing a website with a REST-backend and XHR-requests to retrieve data from the underlying database requires a lot of early-on local testing. However, in this case the resource is coming from a different origin and modern web browsers block them (CORS error). Is there any way to bypass this behaviour in the development stage?
There are many different possibilities to answer this question. We will go top down beginning with the browser.
Most of the browsers support the html input tag of type "email" and most of them would automatically warn the user about a wrong format of the address. However there are many standards of email address pattern. Furthermore the user might disable the browser validation, so we should not rely on this.
The second station is the javascript of the browser. Probably the easiest way to validate the email address is to use a regular expression an match the input against this expression. However the user may disable the javascript or send a request in other way than browser. Therefore it's absolutely necessary to validate the email address on the server side. This might be done by a regular expression, but some more sophisticated systems would check the MX record of the domain given in the email address, to be sure it might be a real address of a real mail server.
Use automated UI Test, which is possible with the Selenium library and a browser driver. The browser driver allows us to run actions in a browser while writing code. The Selenium library is an interface to connect many browsers with the same code base. So now we are able to code a simple test, where a robot is automatically clicking through the website and trying out the login functionality. This technique may also apply to test other important and high priority UI features.
Test login functionality after every code change.
Testing the very common functionality of "login"/"sing in" might be exhausting if we have to test it after every change in the project. Entering the credentials every time, or even if they are stored in the browser, one has to click through it. There must be some better way...
Pages
