For production applications with production accounts

This is typically acceptable for low testing loads (like 1 to 3 a day). However as with most automation. Eventually reCAPTCHA will be triggered.

For most login providers, uilicious is considered a "bot" from the login provider point of view. And will be treated as such. 

While there might be ways to do so in the black market, we do not support such practises. 

Hence, we would instead recommend the following options, for testing with external login providers.

Have an internal login provider?

Limit your external login provider test to once a day. 

And depend on your internal login provider instead to do the bulk of testing. This allows the external login test to keep within the boundaries of a low test load (1 to 3). This approach can be used together with the various other options listed.

Facebook: configure testing accounts for your application

See: https://developers.facebook.com/docs/apps/test-users/

Facebook allow the creation of up to 2000 test users for an application. Ideally using an email domain you control, with a secure password as these accounts would still be valid in your production environment. With limitations.

Create multiple dedicated test accounts

By splitting up your testing load across multiple accounts, you can manage the rate which reCAPTCHA will trigger. This is particularly useful for dedicated testing twitter accounts, that are limited purely to login (no tweets, nor messages)

See: https://stackoverflow.com/questions/7165208/for-twitter-how-to-create-test-user-accounts

Whitelist the testing infrastructure 

Some login providers provide the option to whitelist request ip's and disable 2FA / reCAPTCHA.

Our list of ip addresses is maintained here: https://help.uilicious.com/testing-guides-and-faqs/infrastructure-ip-whitelisting

Setup testing environment to use a "dumb login provider"

A "dumb login provider", once configured will authorise pretty much any login request within its defined scope.

One such example would be http://oauthbin.com/ which when configured, will authorise any login requests. Other DIY alternatives include http://apifest.org/

This is especially useful if your testing environment already includes other security features (such as ip whitelisting). Or your platform was designed to allow anyone to login anyway, mitigating possible security threats.

Did this answer your question?