HTTP access is forbidden error when unlocking account over HTTPS

I am building an Express Application that tries to deploy a Smart Contract in a Quorum Blockchain running in Openshift.

When I run the Application it tries to unlock an account to deploy the contract with.

At this step I get the following error:

# UNLOCKED FAILED.
Error: Returned error: account unlock with HTTP access is forbidden
[0]     at Object.ErrorResponse (/.../my-project/node_modules/web3-core-helpers/src/errors.js:29:16)
[0]     at /.../my-project/node_modules/web3-core-requestmanager/src/index.js:140:36
[0]     at XMLHttpRequest.request.onreadystatechange (/.../my-project/node_modules/web3-providers-http/src/index.js:96:13)
[0]     at XMLHttpRequestEventTarget.dispatchEvent (/.../my-project/node_modules/xhr2-cookies/dist/xml-http-request-event-target.js:34:22)
[0]     at XMLHttpRequest._setReadyState (/.../my-project/node_modules/xhr2-cookies/dist/xml-http-request.js:208:14)
[0]     at XMLHttpRequest._onHttpResponseEnd (/.../my-project/node_modules/xhr2-cookies/dist/xml-http-request.js:318:14)
[0]     at IncomingMessage.<anonymous> (/.../my-project/node_modules/xhr2-cookies/dist/xml-http-request.js:289:61)
[0]     at IncomingMessage.emit (events.js:327:22)
[0]     at endReadableNT (_stream_readable.js:1224:12)
[0]     at processTicksAndRejections (internal/process/task_queues.js:84:21)

However, the endpoint of my Quorum node is https.

Here is the code causing the error:

const web3 = new Web3(HTTPS_QUORUM_ENDPOINT);

const account = (await web3.eth.getAccounts())[0];

await web3.eth.personal
      .unlockAccount(account, ACCOUNT_PASSWORD)
      .then((response) => {
        console.log("# UNLOCKED. OKAY.");
      })
      .catch((error) => {
        console.log("# UNLOCKED FAILED.");
        console.error(error);
      });

Am I doing something wrong? Can it be that the openshift gateway to the Quorum pod is not secured, even though the Route is?

Solution

the latest quorum release inherits upstream behaviour whereby it disallows unlock via HTTP-RPC for security reasons. There is a command line flag --allow-insecure-unlock which can be passed when starting geth which will re-allow this.

This is described in the upstream geth command line options here: https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options

(Note that geth doesn't actually support HTTPS, so that HTTPS_QUORUM_ENDPOINT must actually be using HTTP, or I'm guessing it uses HTTPS to connect to a reverse proxy which then attaches to geth over the HTTP-RPC port.)