[BUG] Can I set api request headers in the in app browser ?

[brianoflondon]

Describe the bug I'm not sure if this is your fault, or mine or if this is even possible on mobile.

I want to set a Header with a bearer token within the browser in Hive Keychain. I get a very hard to track down failure but I think it relates to this fragment.

apiLogin is set in the set up of my Vue 3 app

const api = axios.create({ baseURL: apiURL })
const apiLogin = axios.create({ baseURL: apiLoginURL })

export default boot(({ app }) => {
  // for use inside Vue files (Options API) through this.$axios and this.$api

  app.config.globalProperties.$axios = axios
  // ^ ^ ^ this will allow you to use this.$axios (for Vue Options API form)
  //       so you won't necessarily have to import axios in each vue file

  app.config.globalProperties.$api = api
  // ^ ^ ^ this will allow you to use this.$api (for Vue Options API form)
  //       so you can easily perform requests against your app's API

  app.config.globalProperties.$apiLoginURL = apiLogin
})

Later in my code, after fetching a token from my back end api verifying signatures from Hive Keychain:

      if (hiveAccname in this.users && this.users[hiveAccname].apiToken) {
        console.log("apiTokenSet successful", hiveAccname)
        apiLogin.defaults.headers.common[
          "Authorization"
        ] = `Bearer ${this.users[hiveAccname].apiToken}`
        // need to test if the API token is working
        return true
      }

To Reproduce Steps to reproduce the behavior:

1. Go to https://dev.v4v.app in the browser in Hive Keychain
2. Open the side bar
3. Put in your hive name and login with Keychain

You can see the signature happens find, but the code fails when trying to set the header

https://github.com/brianoflondon/v4vapp-frontend-v2/blob/151-authenticate-with-the-api-server/src/stores/storeUser.js#L333

Expected behavior On a desktop machine this works as expected.

Screenshots If applicable, add screenshots to help explain your problem.

Smartphone (please complete the following information):

• Device: iPhone 14 Pro Max
• OS: iOS
• Version latest

Additional context Add any other context about the problem here.

[brianoflondon]

Some further information: I got HAS working as a second way to authenticate and that uses exactly the same code to set the header with the bearer token. That works (both within the Hive Keychain browser and outside it).

https://dev.v4v.app/

should be up and running and I'm not going to be changing it for the next few hours.

[brianoflondon]

I've now gone live with this on my main v4v.app site so the problem is real for me.

The code runs fine on all the other browsers on my iPhone except that I can't do a keychain login.

[brianoflondon]

OK I think I've found an incosistency which I will be able to sort out in my back end but I'll highlight here.

This is the response from the desktop version of Keychain from a call to keychain.login

{
  "success": true,
  "error": null,
  "result": "1f1a276dc028452449587c7fa--------44d6c028f45ddacc8149619b823-------e6408e44b54eab968d53638",
  "data": {
    "type": "signBuffer",
    "username": "brianoflondon",
    "message": "visa teach buffalo brianoflondon 1707737139.971039 0079c763-31bc-4e3b-8d38-11e4bd064a79",
    "method": "Posting",
    "title": "Login",
    "key": "posting"
  },
  "message": "Message signed succesfully.",
  "request_id": 7,
  "publicKey": "STM7B1eanwUQhXa8tdabTi2RxHnXWtyMBd6iJDZ3Z2QA6rKHQY2WJ"
}

And this is the same thing from the in-app browser iOS version of Keychain:

{
  "success": true,
  "error": null,
  "data": {
    "type": "signBuffer",
    "username": "brianoflondon",
    "message": "pave reject cousin brianoflondon 1707737157.105329 ff734f11-756c-4d44-b6a7-c849966e9837",
    "method": "Posting",
    "title": "Login",
    "domain": "https://dev.v4v.app/"
  },
  "request_id": 19,
  "result": "1f7d00136aed749495----------ec9f0d4423b3257cc2f60217a2caed8afebc872e-------34229387dc7a29609",
  "message": "Message signed succesfully.",
  "publicKey": "STM7B1eanwUQhXa8tdabTi2RxHnXWtyMBd6iJDZ3Z2QA6rKHQY2WJ"
}

I believe the lack of the key key in the second one is killing my API but I'll fix that on my back end, but this kind of thing does cause real problems.

[brianoflondon]

In my case this was fixed by not relying on the existance of the key in the response but I would like it if it was there in the response from the iOS app browser.