Add possibility to use an external web interceptor to receive the OAuth tokens instead of creating an O2ReplyServer

[Timac]

In order to catch the OAuth callback, O2 creates a local web server running with the registered OAuth callback port. While this generally works, there are some cases where this causes problems:

• there is already on the machine a local server running with the specified port
• there might be some firewall, antivirus and other tools that block the local web server.

To solve these issues, it is now possible to use an external web interceptor in O2 instead of creating an O2ReplyServer.

Each O0BaseAuth subclasses (O1, O2, O2Facebook, ...) now have a new parameter 'inUseExternalInterceptor' in their constructor. By default this is set to false and use the old O2ReplyServer mechanism.

If you set this parameter to true, the O2ReplyServer won't be created. Instead the application using the O2 library has to intercept itself the OAuth callback and then call the new O2 function processOAuthCallbackFromExternalInterceptor(const QString &inURLString). The O2 library will then finalize the OAuth setup.

---

Here is an example on how you can reproduce such an issue on macOS:

1. Open a Terminal window and type python -m SimpleHTTPServer 8888. This creates a local web server running on the port 8888. You can open in your favorite webbrowser the page http://127.0.0.1:8888 and confirm that you see the content of your home.
2. Compile and run the example 'facebookdemo' and try to link a Facebook account

Result: The local web server will catch the OAuth callback URL and adding the OAuth account will fail in 'facebookdemo'.

---

The O2 changes also include a new example project called 'facebookexternalinterceptordemo'. It does the same as the 'facebookdemo' example except that it doesn't create a local web server with O2ReplyServer. Instead when 'FBDemo::onOpenBrowser(const QUrl &url)' is called, it creates a web window with a web interceptor mechanism. When you enter the Facebook credentials, the callback url is catched in the web window and the code is passed to the O2 library to finalize the OAuth linking.

1. Open a Terminal window and type python -m SimpleHTTPServer 8888. This creates a local web server running on the port 8888. You can open in your favorite webbrowser the page http://127.0.0.1:8888 and confirm that you see the content of your home.
2. Compile and run the example 'facebookexternalinterceptordemo' and try to link a Facebook account

Result: Note that you are able to link to your Facebook account.

[pipacs]

The reply-server's port is already configurable via the O0BaseAuth::localPort property.

[Timac]

Having a local web server (reply-server) running is not reliable: the local web server might be blocked by some tools installed on the computer, the port you want to use might already be in use and you don't know it. Changing the port would not solve the problem. The external web interceptor approach is much more reliable as there is no reply-server running.

[pipacs]

I still don't get the use case -- finding a free port is trivial, and networking on the loopback interface is almost always allowed, unless you have some really strange setup. Not to mention the example is actually running a web server on the local host on a fixed port...

Perhaps you could be more specific describing the use case, and then let's find a solution that is less intrusive than the one you proposed.

[Timac]

I use O2 in a software and have got around 20 users which reported the impossibility to add OAuth accounts. The use case is exactly what you described:

networking on the loopback interface is almost always allowed, unless you have some really strange setup

Some of these users had a server running on the OAuth port. Since the port is registered in the callback url, I don't see how I could use another free port.

But for most of the users having such an issue, the OAuth port was reported as free and the O2ReplyServer was successfully created. However the O2ReplyServer simply never received any data. I could not identify a single root case of the issue. It seems that some antivirus/firewall are blocking the O2ReplyServer to receive data.

Using an external web interceptor - instead of an O2ReplyServer - solved the issue. The pull request is indeed quite important but I tried to make the minimum amount of changes as possible: the use of an external web interceptor is an optional feature you need to opt in.

Thanks for the feedback!

[pipacs]

So I guess the use case is real, if somewhat mysterious. Let's continue with your approach then, but in a backwards-compatible way. Could you please

• Add an extra property to O0BaseAuth which enables/disables the reply server
• The property's default should reflect the current state, e.g. the reply server should start unless clients explicitly set this property
• The reply server will be created in O1::link() and O2::link(), if needed, before the code that starts it
• Could you just make onVerificationReceived public? Then there won't be a need for processParams...()
• Remove the changes made to the O1/O2 specializations. The new behaviour can now be contained entirely within the example app

[Timac]

The requested changes have been pushed.

[pipacs]

Thanks, looking great now, but still changes 21 files. Could you please minimise the changes, in order to prove we are still backwards compatible.

[Timac]

Thanks for the feedback. There are 18 files that require a change in order to add the feature:

• 10 files are for the example facebookexternalinterceptordemo
• 6 files for the feature: o0baseauth.h, o0baseauth.cpp, o1.h, o1.cpp, o2.h, o2.cpp
• 2 files to make onVerificationReceived public: o2facebook.h, o2uber.h

But you are right that 3 files shouldn't have been changed: o1dropbox.h, o2google.cpp, o2skydrive.cpp I removed these changes and now only 18 files are been modified.

[pipacs]

Thanks!